Mensajería transaccional

El mensajería transaccional es un conjunto de técnicas arquitectónicas que garantizan la consistencia entre los cambios de estado locales (DB/caché) y los mensajes en el bróker/bus. Objetivo: «el estado registrado ↔ el mensaje no se pierde ni se duplica» cuando se producen fallos, retrases, escalas y multitenantes.

1) Semántica de entrega

At-most-once: rápido y barato, posibles pérdidas, no hay tomas.
At-least-once: no pierde mensajes, las tomas son posibles → se requiere idempotencia.
(Efectivo) Exactly-once: no hay pérdidas y no hay tomas visibles para los efectos de negocio, se logra mediante una combinación de técnicas (outbox/inbox, transacciones de productor/consumer, dedoop).

2) Por qué las «dos escrituras» son peligrosas

La lógica ingenua de «primero anotamos en el DB, luego enviamos al bus» (o viceversa) se rompe al caer entre los pasos: se registran los datos y se pierde el evento; o el evento se ha ido y no hay datos. El mensajería transaccional elimina esta brecha.

3) Patrones básicos

3. 1 Outbox (fabricante)

En una transacción local, escribimos un cambio profesional y una fila en la tabla 'outbox'; un pablisher separado lee outbox y publica en un broker con retrayas y backoff. Se excluyen las pérdidas; las tomas son atenuadas por la idempotencia en los consumidores.

3. 2 Inbox/Idempotent Consumer (consumidor)

Antes de realizar el efecto, el consumer hace 'INSERT' en 'inbox (consumer, event_id)' como clave principal. Conflicto de clave = evento ya procesado → omitido. Así se logra un «exactly-once efectivo».

3. 3 Read-Process-Write con transacción offset

Plantilla para buses orientados a logs: el consumer lee batch, en la misma transacción registra cambio de negocio y «offset pasado». Después del commit, el broker considera que los mensajes han sido consumidos. Esto elimina «leído → caído → repetido» sin tomas en el efecto.

3. 4 TSS/Sagi para efectos interservicios

Cuando se necesita un proceso multi-paso coherente, se utilizan TCC o sagas; los mensajes son el transporte de comandos/eventos, y la transaccionalidad es a nivel de pasos y compensaciones.

4) Productoras y consumidoras idempotentes

Productor: 'message _ id '/' idempotency _ key' estable, volver a enviar con la misma clave no crea nuevos efectos en los suscriptores; mantenga la secuencia (sequence) por clave.
Consumer: 'inbox' + idempotencia empresarial (upsert/merge, verificación de la última versión/revisión).

5) Orden y causalidad

Lote por clave de negocio (por ejemplo, 'aggregate _ id', 'tenant _ id') para que los eventos de un solo objeto lleguen en orden.
Dentro del lote, guarde los números consecutivos/marcas de tiempo; en el redrive de DLQ, observe «por clave y en serie».
Si el orden global no es crítico, proporcione un orden local por clave y confirme los invariantes de dominio.

6) Offsets y fijación de efectos

Opción A: «Offset in DB»

Escribe el «último offset procesado (partition, offset)» en la misma transacción donde cambias los datos del dominio. En el restart, continúe con el siguiente offset, evitando el efecto repetitivo.

Opción B: «Transacción del corredor»

Algunos corredores admiten el registro atómico de mensajes y offsets dentro de una sola transacción de productor/consumidor. Úselo si está disponible, pero siempre complementado con idempotencia en el consumidor.

7) Retrai, backoff, DLQ

Repita sólo los errores retraíbles (timeouts, 5xx), con backoff exponencial y jitter.
No retraíble (schema/validación) - inmediatamente en DLQ con metadatos (tenant, key, offset, causa).
Redrive de DLQ dosificar (batch, rate limit), comprobar el esquema antes de repetir, mantener el orden en la clave.

8) Multi-tenencia y regiones

Incluya 'tenant _ id', 'plan', 'región' en los metadatos de los mensajes y las claves de partición.
Fairness per-tenant: limite la publicación/procesamiento para que el cliente «ruidoso» no saque el presupuesto del resto.
Residency: almacena mensajes y outbox en la misma región que los datos de dominio; replicación interregional: agregados asíncronos.

9) Observabilidad y auditoría

Treking: correlación 'event _ id '/' aggregate _ id '/' saga _ id', durmiendo 'read → process → write/commit'.
Métricas: valor de publicación/procesamiento (p95/p99), porcentaje de éxito, tasa DLQ, éxito de redrive, «duplicados suprimidos».
Registros: brevemente para el éxito; detalles sobre los errores (causa, intento, clave, offset).
Auditoría: quién rediseñó/retransmitió, qué trampolín y con qué resultado.

10) Seguridad y cumplimiento

Minimice el PII en payload; enmascarar cuando se transfiera a DLQ/registros.
Firme/cifre los mensajes para los buses externos; utilice mTLS entre servicios.
Administre el período de retención y el «derecho al olvido» por tenant/region.

11) Esquemas de integración estándar

1. Fuente de servicio (write-side)

Transacción local: registro de dominio + outbox.
Pablicher: batches, 'SKIP LOCKED', backoff, límites per tenant.
Monitoreo de la laguna 'now − occurred_at'.

2. Servicio al consumidor (read-side)

Leer batch → intentar 'INSERT inbox (consumer, event_id)' → cuando tenemos éxito realizamos el efecto.
En la misma transacción, fijamos el «offset pasado» (opción A) o confiamos en la transacción del broker (opción B).
En el error: retray o DLQ por política.

3. Proyección/vista materializada

Sólo los apdates idempotentes (upsert), las llaves compactas del dedup, la conciliación periódica de las sumas de control.

12) Plantillas de configuración (ejemplo)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) Lista de verificación antes de la venta

• Eliminada la «doble escritura»: outbox en el productor o fijación de offset y efecto en una sola transacción en el consumer.
• Consumer idempotente: 'inbox '/dedup magazine, idempotencia empresarial de las operaciones.
• Partición por clave de negocio, se sigue el orden local.
• Retrés con backoff + jitter, clasificación de errores, DLQ con metadatos ricos.
• Redrive dosificado, seguro; Hay playbucks.
• Límites y prioridades multi-tenantes; etiquetas 'tenant _ id/plan/región'.
• Telemetría: lags, fracción de éxitos, «duplicados suprimidos», alertas según p95/p99.
• Se han respetado las políticas de PII/retén/encriptación.
• Pruebas: caída entre pasos, duplicados, orden por clave, redrave masivo.

14) Errores típicos

Enviar al bus y escribir en el DB en pasos separados sin outbox/transacción offset.
Consumer sin idempotencia → duplica los efectos secundarios.
El orden mundial «a toda costa» es costoso y raramente justificado; Hay suficiente orden en la llave.
Un redrave masivo sin límites → un incidente secundario.
La falta de traysing/lag métrica → «degradación oculta».
Mezcla de PII en DLQ/logs.

15) Recetas rápidas

Eventos SaaS: Outbox + consumer idempotente (inbox), partitura por 'tenant _ id: aggregate _ id'.
ETL/proyecciones: Lectura-proceso-escritura con fijación offset en una sola transacción, batch 500-1000, upsert.
Alta carga: charding pablishers, 'SKIP LOCKED', WFQ per tenant, control de la laguna.
Zona de cumplimiento estricto: outbox regionales, encriptación de payload, retén y auditoría de redrives.

El mensajería transaccional es una disciplina de conexión de datos y mensajes. Al combinar outbox/inbox, idempotencia, fijación offset junto con efectos y retrases controlados con DLQ, se obtiene un comportamiento práctico exacto-once sin bloqueos globales y se mantiene SLO incluso cuando se producen fallos, picos y una compleja operación multi-tenant.