El error que rompe tus microservicios en silencio ⚠️
Si guardas datos en tu base de datos y luego envías un evento a una cola (SQS, Kafka, RabbitMQ), estás jugando a la ruleta rusa con tu consistencia de datos. El problema es el "Dual-Write". No existe una transacción ató
Artículo
Una lectura sobre tecnología y sistemas digitales, escrita para ir al punto y dejar claras las ideas principales.
Tema principal
arquitectura de software
Fuente
dev.to
Puntos clave
- Si guardas datos en tu base de datos y luego envías un evento a una cola (SQS, Kafka, RabbitMQ), estás jugando a la ruleta rusa con tu consistencia de datos.
- El problema es el "Dual-Write". No existe una transacción atómica que abarque dos sistemas distintos. Si el proceso cae justo después del commit de la DB pero antes de enviar el mensaje, tu sistema queda inconsistente: e
- La solución profesional es el Transactional Outbox Pattern.
- La clave es dejar de intentar escribir en dos sitios y empezar a escribir en uno solo, pero de forma inteligente:
Bloque 1
Si guardas datos en tu base de datos y luego envías un evento a una cola (SQS, Kafka, RabbitMQ), estás jugando a la ruleta rusa con tu consistencia de datos.
El problema es el "Dual-Write". No existe una transacción atómica que abarque dos sistemas distintos. Si el proceso cae justo después del commit de la DB pero antes de enviar el mensaje, tu sistema queda inconsistente: el pedido existe, pero el almacén nunca se enteró.
Bloque 2
La solución profesional es el Transactional Outbox Pattern.
La clave es dejar de intentar escribir en dos sitios y empezar a escribir en uno solo, pero de forma inteligente:
Bloque 3
• Tabla Outbox: Guardas el registro de negocio y el evento a publicar en la misma transacción de la base de datos. • Relay Worker: Un proceso independiente lee los eventos pendientes de esa tabla y los publica en la cola. • Garantía de entrega: Si el Relay falla, los eventos siguen en la DB esperando ser procesados. • Idempotencia: El consumidor debe ser capaz de manejar duplicados, ya que el patrón garantiza entrega "al menos una vez".
Diseñar para el "happy path" es el camino más rápido hacia una madrugada de incidentes en producción. Como arquitectos, debemos diseñar para el fallo.
Bloque 4
¿Ustedes cómo están resolviendo la consistencia eventual en sus arquitecturas distribuidas?