Entrega, leases y efectos duplicados
Razona sobre el hueco entre hacer el trabajo y registrar que se hizo.
AL TERMINAR, PODRÁS
- Comparar la entrega como máximo una vez y al menos una vez
- Explicar la expiración de un lease y los workers obsoletos
- Ubicar la frontera de una afirmación de «exactamente una vez»
Descripción del diagrama: 1. Cola → Worker: trabajo 9 · concesión 30 s; 2. Worker → Pagos: charge (key=job-9); 3. Worker → Cola: aviso (ack) (lost); 4. Cola → Worker: concesión vencida: trabajo 9 otra vez; 5. Worker → Pagos: charge (key=job-9); 6. Pagos → Worker: mismo resultado, sin segundo cobro
El hueco del aviso de terminado
Un worker produce un efecto y luego avisa que terminó (acknowledge, ack).
Si se cae después del efecto pero antes de avisar, otro worker puede repetir el efecto. Avisar primero crea el riesgo contrario: una caída puede perder el trabajo. La entrega como máximo una vez (at-most-once) prefiere evitar repeticiones, pero puede perder intentos; la entrega al menos una vez (at-least-once) reintenta el trabajo sin aviso de terminado, pero permite duplicados.
Son propiedades de la entrega, no garantías sobre la cantidad de efectos de negocio. Un proveedor de correo, un sistema de pagos o una base de datos pueden necesitar su propio contrato de deduplicación.
Un lease es una posesión temporal
Un lease (concesión temporal) sobre un trabajo reservado (claimed) permite que otro worker lo recupere después de un plazo.
Pero un worker cuyo lease expiró puede simplemente estar lento y reanudar después de que un worker nuevo reservó el trabajo. Asocia un token de reserva o una generación que siempre crece, y exígelo para el aviso de terminado y las escrituras protegidas. Un token de cercado (fencing token) solo funciona cuando el recurso que recibe la operación lo comprueba; generar un token por sí solo no detiene los efectos obsoletos.
Dimensiona y renueva los leases según duraciones observadas, contando con pausas del proceso y con el comportamiento de los relojes.
Haz explícita la frontera del efecto
Un manejador idempotente produce un resultado aceptable cuando se vuelve a intentar la misma operación prevista.
Una clave única en la base de datos puede deduplicar un efecto registrado cuando el efecto y el registro de deduplicación se confirman (commit) de forma atómica. Un proveedor externo necesita un mecanismo de idempotencia compatible, o tendrás que aceptar y mitigar los duplicados restantes. Un outbox (bandeja de salida) registra el estado de negocio y la intención de entrega en una sola transacción local, y luego publica por separado.
Evita una ventana de pérdida, pero quien publica todavía puede enviar dos veces. Toda afirmación de «exactamente una vez» debería nombrar la frontera del sistema y las suposiciones sobre fallas.
ERROR FRECUENTE
Marcar una clave de deduplicación antes de un efecto externo arriesga perder efectos; marcarla después arriesga duplicados. La frontera atómica es lo que importa.
INTÉNTALO TÚ
Dibuja una línea de tiempo con el efecto, el aviso de terminado y una caída entre ambos. Luego diseña un ID de operación único y explica dónde debe hacerse cumplir para evitar efectos de negocio duplicados.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Agrega generaciones de reserva al diseño de Relay y define un manejador de ejemplo idempotente. Documenta un efecto externo que tu diseño no puede hacer exactamente una vez por sí solo.