01Consistencia eventual (sin romanticismo)
⏱
QUÉ SE ACEPTA
Ventanas de inconsistencia
ReplicasProyeccionesCaches
Tras publicar un evento, otros sistemas pueden tardar segundos o más en reflejar el nuevo estado. Los SLAs y los diseños de UX deben asumirlo (mensajes “pendientes”, indicadores de sincronización, no depender de lectura inmediata cross-service sin diseño explícito).
✓
READ YOUR OWN WRITES
Sigue siendo local
Misma DBSesiónRouting
El usuario puede ver su propio cambio al instante si la lectura va al servicio/BD que hizo el commit. Leer otro microservicio justo después del evento puede fallar sin compensación — ahí no es “eventual” por arte de magia, es diseño incorrecto.
02Transactional outbox — publicar sin perder la verdad
Misma transacción: negocio + “pendiente de enviar”
Servicio
UPDATE negocio
+
Tabla outbox
INSERT fila del evento
→
Publisher / relay
lee outbox y envía al broker
→
Broker
Kafka / SQS / …
Evita el antipatrón “commit en BD y luego envío al bus”: si el proceso muere entre medias, o pierdes el evento o duplicas sin control. Con outbox, el evento queda persistido en la misma transacción que el cambio de negocio; un relay fiable hace el puente al mensajero.
En código legacy sin outbox, los seniors piden al menos idempotencia + reconciliación; con outbox, la conversación pasa a throughput del relay y orden por partición/partición clave.
03Consumidores idempotentes
🔁
AT-LEAST-ONCE EN EL MUNDO REAL
El mismo evento puede llegar dos veces
RedeliveryRebalanceCrash antes del ack
Si el mensaje puede repetirse, el efecto secundario (cargo en cuenta, envío de email, stock) debe ser idempotente: misma clave de negocio + restricción única, tabla de deduplicación por eventId, o modelo naturalmente idempotente (PUT con versión).
Pregunta que te harán en revisión: “¿Qué pasa si este handler se ejecuta dos veces con el mismo payload?”
04Antipatrones frecuentes
Antipatrón
Síntoma
Enfoque sano
RPC disfrazado de evento
Cola de “requests” con correlation sin modelo de negocio; acoplamiento en tiempo.
Comando síncrono explícito o cola de comandos con contrato claro; eventos para hechos ya ocurridos.
God topic
Un único stream con tipos mezclados; consumidores filtran en vano.
Separar por bounded context o por tipo estable; gobierno de esquemas.
Sin versionado
Deploy rompe consumidores silenciosamente.
Schema registry, campos opcionales, contratos de compatibilidad.
Confiar en orden global
Asumir orden entre agregados distintos.
Orden solo dentro de partición/partición por clave de negocio; diseñar para causalidad débil.
🔗
Encaje con el resto de dev-notes
Resiliencia / mensajería cubre retries, DLQ y backpressure; EIP nombra router, splitter o canal; EDA decide qué eventos existen y cómo evolucionan. Kafka u otro broker son la herramienta — la conversación de negocio sigue siendo de contratos y límites entre contextos.