Entre servicios, generalmente intercambias consistencia fuerte por consistencia eventual, y te apoya en CQRS y event sourcing para hacerlo práctico y correcto.
Después de un cambio, las réplicas convergen "pronto" en lugar de instantáneamente. Aceptable para la mayoría de los flujos comerciales (un recuento de inventario puede retrasarse un segundo), inaceptable para algunos (una verificación de saldo bancario).
Separa el modelo de escritura de uno o más modelos de lectura.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Las lecturas se escalan y se remodelan independientemente de las escrituras; el modelo de lectura se actualiza a partir de eventos, por lo que es eventualmente consistente.
Almacena la secuencia de eventos como fuente de verdad, no solo el estado actual. El estado actual es un pliegue sobre eventos.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Técnica | Ganancias | Costos |
|---|---|---|
| Consistencia eventual | Disponibilidad, escala | Lecturas obsoletas, conflictos |
| CQRS | Escala de lectura/escritura | Dos modelos para mantener sincronizados |
| Event sourcing | Auditoría, reproducción, historial | Evolución de esquema/evento, complejidad |
No adoptes event sourcing en todas partes — es poderoso pero pesado. Úsalo donde la auditoría/historial realmente importa.
Los sistemas distribuidos no pueden tener consistencia fuerte, disponibilidad y tolerancia a particiones todos a la vez, por lo que el diseño senior trata sobre elegir dónde es aceptable la consistencia eventual.
CQRS y event sourcing te dan las herramientas para hacer que la consistencia eventual sea confiable y auditable — pero cada una agrega complejidad real, así que aplícalas quirúrgicamente, no por defecto.