Los plazos limitan cuánto se espera; las leases limitan durante cuánto tiempo se reconoce a un propietario. Ninguno detiene necesariamente un proceso remoto cuando vence. Un worker pausado puede despertarse y terminar una escritura después de que otro haya adquirido el trabajo.
El diseño debe separar espera del cliente, ejecución, propiedad y resultado durable. Esa separación permite recuperar fallos sin afirmar que un timeout equivale a una operación nunca realizada.
Tres relojes con contratos distintos
| Mecanismo | Pregunta que responde | Límite |
|---|---|---|
| Timeout o deadline | ¿Cuánto presupuesto queda para esperar o intentar? | No prueba si un efecto remoto ocurrió. |
| TTL de un dato | ¿Cuándo deja de considerarse vigente esta entrada? | No garantiza notificación puntual ni cancela al usuario del dato. |
| Lease de propiedad | ¿Durante cuánto tiempo se reconoce a este dueño? | La expiración no impide por sí sola escrituras tardías. |
Dentro de un proceso, un reloj monotónico permite medir duración sin depender de ajustes del reloj de pared. Entre máquinas no se asume que sus relojes estén perfectamente sincronizados. La autoridad del recurso determina qué vencimiento acepta; un cliente no amplía un hold cambiando su reloj local.
Presupuesto de una operación
El timeout incluye conexión, envío, servicio y devolución, según la biblioteca. La aplicación debe conocer qué fases cubre. Un presupuesto total se reparte entre dependencias y reintentos, dejando tiempo para responder o consultar estado.
Una orden con tres intentos de cinco segundos no cabe automáticamente en una petición de diez segundos. Backoff y jitter consumen presupuesto; multiplicar reintentos en varias capas puede producir más carga justo durante el incidente. La admisión necesita limitar también ese trabajo.
Si se agota el plazo después de enviar un cobro, el resultado es incierto. Se conserva la identidad de operación, se consulta o reintenta bajo un contrato compatible y se reconcilia antes de abrir otro intento incompatible. Idempotencia protege el efecto previsto, mientras el timeout protege la espera.
Adquirir, renovar y liberar
Una adquisición coordinada registra propietario, vencimiento y, cuando corresponde, una versión de propiedad. La renovación sólo es válida si el ejecutor sigue siendo el dueño. La liberación compara esa identidad de forma atómica; una lectura y un borrado separados pueden eliminar la lease que obtuvo un sucesor.
El sistema de boletaje conserva la reserva firme y su expiración en PostgreSQL. Redis puede facilitar coordinación provisional y mapas, pero perder una clave no concede una venta. El hold que confirma una operación debe seguir vigente y pertenecer al actor autorizado.
En etcd, una lease tiene un TTL elegido por el servidor y keepalive. Sus claves se eliminan al expirar o revocarse. La API de lock devuelve una clave de propiedad que puede validarse dentro de una transacción de etcd. Es una frontera concreta, no protección automática para cualquier base o proveedor externo.
El propietario viejo puede regresar
El diagrama muestra dos ejecuciones alrededor de un vencimiento. El recurso aplica la condición de propiedad antes de aceptar el efecto.
--- config: look: handDrawn --- flowchart TD acquire["Adquirir propiedad<br/>Versión vigente"] --> worker["Worker ejecuta"] worker -->|"Pausa o pérdida de renovación"| expiry["Lease vence<br/>Nuevo dueño puede adquirir"] expiry --> successor["Sucesor<br/>Versión posterior"] worker -->|"Escritura tardía"| boundary["Recurso valida<br/>propiedad o fencing"] successor --> boundary boundary --> result["Aceptar vigente<br/>Rechazar antiguo"]
Un fencing token es una versión monotónica cuya comparación realiza el recurso protegido, con la actualización necesaria en la misma frontera atómica. El recurso rechaza versiones inferiores a la última que aceptó. Eso no prueba por sí solo que la lease siga vigente ni rechaza al dueño antiguo antes de observar una versión posterior: si el contrato exige vigencia, también se valida autoridad y plazo. Tener un número en el worker no basta si la base acepta cualquier petición. Un lease ID tampoco debe asumirse como token monotónico.
La condición puede proteger un cambio local y su resultado durable. Si el efecto es enviar un email o llamar a una API que no valida esa propiedad, el fencing local no lo cerca. Se requiere cooperación del destino, idempotencia compatible o un contrato que admita reconciliación y compensación.
Recuperar sin dos decisiones válidas
Al recuperar un pendiente, se comprueban identidad, versión y resultado conocido. Un sucesor no borra la historia para comenzar de cero; coordina qué intentos pueden continuar y cómo se registran respuestas tardías.
En una outbox, reclamar un evento con plazo puede permitir otro publicador después de un fallo. Un ack tardío del dueño anterior no debe sobrescribir el estado de otro intento mediante una actualización incondicional. Aun con esa coordinación, puede haber publicación repetida, por lo que el consumidor conserva deduplicación.
Vencer una lease no exige compensar inmediatamente un efecto incierto. Una acreditación que pudo completarse debe resolverse antes de devolver fondos como si nunca hubiera ocurrido. Las decisiones de cancelación y recuperación también necesitan condiciones de concurrencia.
Elegir plazos y comportamiento de fallo
El plazo considera latencias observadas, pausas, carga y coste de mantener recursos. Una lease demasiado corta provoca reclamaciones frecuentes; una demasiado larga retrasa recuperación. Su renovación también puede fallar por una partición aunque el dueño siga ejecutando.
Si la autoridad no está disponible, continuar escribiendo por intuición puede violar el contrato. Algunas lecturas degradan con datos viejos; una venta puede requerir rechazar o dejar pendiente la operación. Una única política para todas las rutas confunde disponibilidad con seguridad.
Verificar pausas y respuestas tardías
Se detiene un worker después de adquirir, se permite que otro reclame y se reanuda el primero. El ensayo comprueba la condición en el recurso, no sólo que el coordinador muestra al nuevo dueño. También se pierden respuestas de renovación y de efectos externos.
Se observan renovaciones fallidas, reclamaciones, antigüedad de pendientes, rechazos por versión y duración de reconciliaciones. La lease ofrece propiedad temporal bajo supuestos explícitos; el resultado durable y la protección del destino completan el contrato.
Referencias: Lease API de etcd, API de concurrencia y timeouts, reintentos y backoff.