La compra impulsiva de ropa B2C promedia 2 a 3 ítems por carrito. La compra de reposición mensual de una cadena de farmacias B2B promedia 800 líneas de pedido distintas, con 5 unidades de cada línea. Las matemáticas de la carga (Payload) destruyen arquitecturas débiles.
La Tiranía del N+1 Problem
El error técnico más común en desarrollo web: El problema N+1.
Imaginá que un comprador sube un Excel con 500 códigos para cotizar (RFP). El programador inexperto crea un bucle:
Para cada linea (1 a 500): - Consultar Base de Datos por precio - Consultar Base de Datos por stock - Calcular IVA
Eso significa hacer 1.500 consultas a la base de datos en un segundo. El servidor responde con Error 504 (Timeout). El cliente se queda mirando una pantalla blanca.
Arquitecturas Asíncronas B2B
Plataformas nacidas para B2B reestructuran el cerebro de la aplicación. Al subir los 500 ítems, se hace una única consulta masiva (Bulk Query):
- "Deme el precio y stock de los IDs [1, 5, 8, ... 500] para la Lista de Precio X".
La base de datos responde un solo bloque gigante. La memoria RAM procesa la matemática del IVA de los 500 ítems localmente. Todo ocurre en menos de medio segundo.
Background Jobs en el Checkout
Aun así, transformar 500 ítems en un Pedido (Order) final, enviarle los mails al gerente de aprobaciones, descontar el crédito y generar la integración con el ERP tarda. No podés tener al usuario mirando la "ruedita girando" durante 15 segundos porque puede apretar "Actualizar" y generar un pago doble.
Se usan Message Queues (Colas de tareas, tipo RabbitMQ o Redis/Horizon):
- El cliente aprieta "Pagar".
- La web inmediatamente lo lleva a la pantalla de éxito: "Su pedido gigante está siendo procesado en segundo plano. Le avisaremos por mail en 1 minuto".
- El servidor detrás de escena, sin apuro, procesa las miles de validaciones contables y le dispara los comprobantes cuando termina, asegurando resiliencia extrema al sistema.
