Un pedido, un pago capturado y un paquete entregado son hechos distintos. Conéctalos con publicación fiable, consumidores limitados y recuperación responsable.
Autor
Anichur Rahaman
El lunes, una revisión de integración contiene 1,900 operaciones elegibles. Un consumidor confirma 1,412 aplicadas; quedan 488:480 esperando recuperación y 8 retenidas para investigar. Es una cohorte ilustrativa, no un incidente real. Importa saber qué se debe hacer, por qué espera y quién responde, además de una etiqueta “sincronizado”.
El diseño por eventos permite que un responsable registre un hecho y otras partes autorizadas reaccionen mediante contratos. Puede hacer visibles obligaciones y reducir acoplamientos. Aún necesita aceptación correcta, entrega duradera, estados veraces y conciliación. Los lotes nocturnos o polling también son legítimos si satisfacen frescura y recuperación.
Un comando pide algo al responsable: reservar dos chaquetas o emitir un reembolso. Este comprueba permisos y condiciones y puede denegarlo. Un evento describe algo registrado, como OrderAccepted o PaymentCaptured; el consumidor reacciona. El nombre no prueba autenticidad, validez ni interpretación de un mensaje entrante. Valida origen y contrato.
Los eventos pueden permanecer en una aplicación modular o cruzar un broker, ejecutarse sincrónicamente o en segundo plano. Laravel documenta los listeners en cola como configuración explícita, no propiedad automática de una clase de evento. Un listener nuevo puede saturar recursos, fallar o romper contratos. Gobierna y prueba; no prometas que checkout nunca será afectado.
Pedido didáctico 1042:dos JKT-M a USD 40, envío USD 5 e impuesto aprobado por finanzas de USD 8:80+5+8=USD 93. Coste asignado de inventario USD 22 por unidad, USD 44 total. Moneda, momento fiscal, valoración, entrega e ingresos son supuestos explícitos, no reglas comerciales universales.
El almacén empieza con 48 unidades, ninguna reservada. La operación responsable asegura 2 antes de prometer stock definitivamente, dejando 46 disponibles. Reservar asíncronamente después de aceptar sin condición puede sobrevender la última unidad. Si la reserva es otro proceso, muestra pendiente hasta confirmarla y coordina vencimiento, cancelación y pago.
La tabla distingue hechos: despachar saca stock físico del almacén; entregar ocurre después. Bajo los términos de propiedad del ejemplo, las 2 unidades en tránsito siguen siendo del negocio hasta la entrega verificada y transferencia de control. No descuentes dos veces por esas ubicaciones y estados.
| Hecho/estado | Significado de stock/pago | Prueba independiente pendiente |
|---|---|---|
| OrderAccepted | Almacén 48; reserva 2; disponible 46 | Reserva válida y aceptación duradera |
| PaymentCaptured | Proveedor capturóUSD 93 | Liquidación/banco y elegibilidad contable |
| ShipmentDispatched | Almacén 46; reserva 0; tránsito 2 | Entrega al transportista; no duplicar coste |
| DeliveryConfirmed | Tránsito 0 al transferir control aquí | Cumplimiento y reconocimiento aprobado |
Autorización, captura, liquidación del proveedor, ingreso bancario e ingreso ganado son hechos diferentes. IFRS 15 vincula ingresos con obligaciones satisfechas y transferencia de control donde aplica. Finanzas debe aprobar política e impuestos reales; un desarrollador no elige el criterio solo por suscribirse a ParcelDelivered.
Solo en este ejemplo, captura crea anticipo de cliente y derecho de cobro a la liquidación de tarjeta; entrega satisface bienes/envío y el momento fiscal aprobado. Inventario trasladó el coste a existencias en tránsito al despachar. La ilustración excluye comisiones, entregas parciales, devoluciones y ajustes; la política real puede variar.
Captura: débito Compensación de tarjetas 93 y crédito Anticipos de clientes 93. Entrega elegible: débito Anticipos 93; créditos Mercancías 80, Envío 5 e Impuesto por pagar 8. Además débito Coste de ventas 44 y crédito Inventario en tránsito 44. Débitos de entrega 93+44=137; créditos 80+5+8+44=137. El handler debe imponer y probar el equilibrio; un asiento equilibrado todavía puede tener fecha, cuenta, importe o política incorrectos.
| Asiento didáctico | Débito | Crédito |
|---|---|---|
| Captura | Compensación de tarjetas 93 | Anticipos de clientes 93 |
| Entrega elegible | Anticipos de clientes 93 | Mercancías 80 + envío 5 + impuesto 8 |
| Coste asignado entregado | Coste de ventas 44 | Inventario en tránsito 44 |
Hay un hueco si la base confirma y el proceso muere antes de enviar. Publicar primero puede anunciar algo que luego revierte. Un outbox transaccional guarda cambio e intención en una transacción local; un relay publica trabajo confirmado. Otro diseño de captura apropiado puede servir con semántica explícita.
El relay puede publicar y caer antes de marcar éxito, generando duplicados. El outbox cierra ese hueco, sin garantizar que almacenamiento, retención o bugs jamás pierdan eventos. Monitoriza pendientes, conserva evidencia recuperable y prueba fallos. RabbitMQ distingue confirmación del publicador y acuse del consumidor: que el broker acepte no demuestra que cada consumidor termine el efecto.
Decide qué debe confirmarse antes de aceptar el pedido. Difiere notificaciones/proyecciones apropiadas, no la corrección de la promesa de stock. Muestra pendientes reales y evita que un proveedor de correo caído deshaga accidentalmente una operación ya aceptada.
Para un efecto local, reclama una clave única adecuada y confirma esa marca, cambio comercial y recibo juntos. Controla duplicados concurrentes atómicamente. Incluye consumidor, origen/identidad y empresa cuando corresponda; IDs iguales de productores distintos no deben suprimir trabajo ajeno. Mensajes distintos pueden representar una misma operación, por lo que también puede necesitarse unicidad comercial.
Stripe documenta webhooks repetidos y desordenados, incluso objetos de evento separados para la misma ocurrencia. Autentica emisor, cuenta y ambiente, conserva recibo duradero y sigue su contrato. Una fila “procesado” no hace atómicos con tu base un envío, correo o reembolso externo.
Para efectos externos guarda referencia duradera y usa idempotencia/consulta admitidas por el proveedor. Ante ambigüedad consulta antes de crear otra operación. Reintentos con espera progresiva y variación, límites de intentos/edad y responsable. Permisos o datos inválidos piden corrección/escalamiento, no repetición infinita. La cola de mensajes fallidos contiene obligaciones sin resolver, no operaciones exitosas.
CloudEvents 1.0.2 proporciona origen/identidad, tipo y versión de especificación. Úsalo si sirve; no determina política contable, confianza ni permisos. Define schema comercial versionado, horas de ocurrencia/registro, referencias y correlación. Versiones por entidad ayudan cuando un productor controla ese orden; no existe orden global automático entre pagos, stock y entregas.
Un timestamp no es clave universal de orden ni duplicados. Si falta prerrequisito, retén, consulta estado autorizado o repara el hueco. No descartes ciegamente un evento antiguo que aún debe producir un efecto. Define corrección, cancelación y llegada tardía en la máquina de estados real.
Entrega datos mínimos a cada audiencia autorizada. Un ID de pedido no permite consultar al cliente; costes, nómina o direcciones no deben difundirse a todos. Puede usarse consulta/proyección versionada autorizada; “nunca consultar al productor” no es universal. Protege colas, fallidos, historial e interfaces operativas.
Reproducir tiene un propósito. La misma clave puede omitir correctamente algo ya procesado, incluso por código con bugs. Reconstruir una proyección segura puede usar handler/versión controlados aparte; corregir finanzas exige reparación autorizada. No borres todas las marcas y repitas efectos reales. Integración por eventos no obliga a event sourcing ni garantiza historial permanente en el broker.
La guía de registros de OWASP complementa el diseño. Construye evidencia protegida que vincule ocurrencia, intento, decisión y resultado real, limitando datos sensibles y retención. Mensajes que desaparecen al confirmar no son auditoría completa; conservar un evento tampoco prueba que se ejecutó el consumidor.
Prueba caídas antes/después de commit, duplicados concurrentes, eventos ausentes/desordenados, credenciales revocadas, timeouts y versiones nuevas. Mide trabajo listo más antiguo, resultados, edad de reintentos, responsables de fallidos y brechas. Un contador de duplicados omitidos no demuestra seguridad total. Concilia elegibles del mismo ámbito, periodo y estado; pedidos no equivalen necesariamente a ingresos reconocidos o depósitos.
La cohorte del lunes: 1,900=1,412 confirmadas+480 recuperándose+8 retenidas. Las 488 siguen visibles hasta conciliarse; no son automáticamente 488 ventas perdidas ni promesa de registrar en minutos. Referencia y responsable ayudan más que una insignia verde.
Empieza con un efecto cuya demora sea aceptable, define responsable/contrato y demuestra recuperación. No existe umbral mágico de tres listeners ni orden obligatorio empezando por stock. Pide a StoreConsole o cualquier plataforma demostrarlo en su versión y proceso habilitados, sin deducir garantías de un diagrama de módulos.
Revisado el 5 de noviembre de 2026. Anichur Rahaman es el creador de StoreConsole. Pedidos, cohortes y cifras contables/de stock son ejemplos sujetos a políticas aprobadas.
Sobre el autor
Anichur Rahaman
Seguir Leyendo
