Imaginemos una base de datos con dos tablas: items y orders . La primera tabla contiene todos los artículos disponibles para la venta. El segundo realiza un seguimiento de todos los pedidos realizados por los clientes. Cada artículo tiene una columna 'cantidad', que dice cuántos de estos artículos están disponibles en stock. Al realizar un nuevo pedido, el backend verifica si la cantidad solicitada no es mayor que la cantidad en stock. Si es así, la orden no se crea. De lo contrario, se crea el pedido y se actualiza la cantidad de artículos disponibles.
El problema es que cuando se crean dos órdenes simultáneamente, ambos cheques se ejecutan al mismo tiempo y se crean dos órdenes (sin saberse una de la otra). Como resultado, hay dos pedidos en DB con una cantidad total ordenada mayor que la cantidad real en stock.
Ya busqué cómo manejar este problema y encontré conceptos como transacciones, bloqueos, aislamiento, etc. Llegué a comprender estos términos, pero aún no entendí qué solución arquitectónica debe implementarse.
¿Qué debo hacer exactamente para resolver este problema? ¿Qué consulta SQL escribir para verificar el stock antes de crear un pedido? ¿Debería envolverlo en una transacción y aplicarle algún nivel de aislamiento? ¿O tal vez solo necesito bloquear las mesas al hacer un pedido? ¿Es posible simplemente hacer que la operación de creación de pedidos espere hasta que se cree un pedido concurrente? Todavía no tengo respuestas a estas preguntas.
Espero tu ayuda. ¡Gracias!
Hay muchas maneras de resolver el problema. Suponiendo que no está tratando de crear un sitio minorista importante aquí, lo más simple es bloquear la fila en artículos.
La forma más fácil probablemente sea ni siquiera verificar hasta después de que se haya realizado la resta.
UPDATE ITEMS set quantity_avail=quantity_avail - $2 where part_num= $1 returning (quantity_avail)Y luego, si el valor devuelto es menor que 0, haga una reversión de la transacción e informe al usuario que ahora está agotado.
Pero ahora, ¿qué sucede si el departamento de envíos lo deja caer al piso y lo rompe mientras lo prepara para el envío?
Para volúmenes bajos a medios, puede implementar el procesamiento en tiempo real. Para un volumen alto, debe conformarse con tiempo casi real.
Para el procesamiento en tiempo real hay dos opciones:
Bloqueo optimista: la aplicación no bloquea los registros que deben modificarse, sino que solo los lee. Cuando finaliza el procesamiento (idealmente después de un breve período de tiempo), la aplicación actualiza los registros con "verificación de concurrencia". Por lo general, los registros incluirán un número de versión, una marca de tiempo o, en casos extremos, se comparará el registro completo. Si la actualización pasa la verificación de concurrencia, entonces todo está bien, la transacción está confirmada y el pedido está completo. Si la verificación de simultaneidad no pasa, es necesario que se lleve a cabo una lógica de compensación para volver a intentar la acción, recuperarla de alguna manera o considerar que falló. El beneficio de esta estrategia es que puede procesar más pedidos con el mismo hardware. La desventaja es que es una solución más compleja, ya que necesita ocuparse de una ruta adicional, no solo de la ruta feliz.
Bloqueo pesimista: la aplicación lee y bloquea todos los registros necesarios. Todos los demás procesos que compiten deben tomar todos los bloqueos en la misma secuencia. Si todos los bloqueos están asegurados, el pedido se puede procesar de forma segura sin temor a contratiempos al final de la tarea. El beneficio de esta estrategia es que es simple de entender y depurar. La desventaja de esta estrategia es que los bloqueos son costosos de obtener y pueden afectar significativamente el ancho de banda de la aplicación, es decir, la cantidad de pedidos por minuto que puede procesar.
Finalmente, para un gran volumen, probablemente deba conformarse con un tiempo casi real , también conocido como procesamiento diferido. Hay dos estrategias:
Si su aplicación puede clasificar los pedidos por algún criterio (región, cliente, tipo de productos, almacén, etc.), puede implementar un microservicio o un conjunto de colas donde cada instancia del servicio/cola atiende a clientes separados o artículos en stock. Esto puede proporcionar un nivel decente de paralelismo en este caso.
Si no puede haber clasificación para los pedidos, entonces una sola cola puede procesar todos los pedidos, uno por uno. Esto puede ser lento para algunas aplicaciones.