Reliable Execution and Delivery
Un timeout informa que no se obtuvo una respuesta dentro del plazo; no demuestra que la operación falló antes de producir su efecto. Para decidir un reintento, conviene separar la intención de negocio, los intentos de ejecución y los efectos observables.
Recorrido
| Documento canónico | Pregunta que permite responder |
|---|---|
| delivery-guarantees | ¿Qué unidad, frontera y supuestos cubre el contrato? |
| at-most-once | ¿Qué pérdida aceptamos para evitar una repetición en esa frontera? |
| at-least-once | ¿Cómo recuperamos progreso y qué duplicados debemos admitir? |
| idempotency | ¿Qué efecto conserva una operación cuando se repite? |
| deduplication | ¿Cómo reconocemos y suprimimos trabajo repetido? |
| exactly-once-semantics | ¿Qué ocurre una vez y dónde termina esa garantía? |
| dual-write-problem | ¿Qué pasa si un efecto se confirma y otra escritura no? |
Conexiones para diseñar
Comenzar por delivery-guarantees y comparar at-most-once con at-least-once. Si se admiten reentregas, evaluar idempotency y deduplication: son respuestas complementarias, no sinónimos.
Después revisar exactly-once-semantics para precisar el efecto protegido y dual-write-problem para encontrar fronteras que la coordinación local no cubre. Estas relaciones forman un grafo de decisiones; el orden sugerido de lectura no es una dependencia formal entre definiciones.
La Perspective Note API Idempotency aplica el canónico a claves, parámetros, intentos concurrentes y retención en una API. Permanece en el área desde la que observa el concepto.
El MOC distributed-transactions continúa desde las fronteras de commit: compara coordinación atómica, compensaciones y reservas para resolver cambios entre participantes.
reliable-messaging aplica estas garantías a publicación y consumo: conecta transactional-outbox, inbox-pattern, idempotent-consumer y dead-letter-queue, distinguiendo sus fronteras y responsabilidades.
resilience-patterns continúa con decisiones de tiempo y carga: deadline delimita el presupuesto completo; retry exige condiciones para repetir; backoff y jitter espacian intentos; circuit-breaker controla admisión ante una dependencia deteriorada.
Preguntas para una revisión
- ¿El timeout deja un resultado desconocido o existe evidencia de que no hubo efecto?
- ¿Estamos contando entregas, ejecuciones o efectos confirmados?
- ¿Cómo se reconoce que dos intentos corresponden a la misma intención?
- ¿Qué impide duplicados cuando los intentos ocurren simultáneamente?
- ¿Cuánto tiempo permanece vigente esa protección?
- ¿Qué escritura o efecto externo queda fuera del commit local y quién lo recupera?
Alcance de esta iteración
Este mapa conecta el cluster inicial de Reliable Execution and Delivery. Durable Execution y Workflow Durability quedan para una iteración avanzada. Los patrones de mensajería tienen sus documentos en Integration and Messaging / Messaging. El MOC organiza el recorrido y las preguntas de diseño, no reemplaza el contenido canónico.