4 posts
Un timeout o un crash no significan que tu petición a la API se haya perdido. Aquí te explicamos cómo las idempotency keys hacen seguros los reintentos, y el patrón de almacenamiento que realmente previene duplicados.
Tu servicio se cae a mitad de una petición . El cliente ve un timeout y reintenta. Ahora tienes dos cargos. El cliente está enfadado. La base de datos es…
Los mutex en memoria desaparecen cuando tu servidor reinicia. Así es como los leases distribuidos con fencing tokens y TTLs evitan trabajo duplicado tras un crash, y dónde aún fallan.
Tu no sobrevive a un . No sobrevive a un OOM, un deployment rollout ni un reinicio de node. En el instante en que el proceso termina, el lock desaparece. Si…
La mayoría de las bibliotecas de circuit breaker lanzan hilos en segundo plano para sondear la recuperación. No los necesitas. Aquí tienes un diseño dirigido por requests que elimina todo el overhead en segundo plano sin sacrificar la corrección.
Cada circuit breaker de producción que he revisado eventualmente lanza un hilo en segundo plano. Puede ser una goroutine de Go, un de Java, o una tarea tokio…
El software crash-only trata cada fallo como un crash y cada inicio como una recuperación. Para los servicios web, esto significa eliminar tu lógica de shutdown y diseñar un estado que sobreviva a un kill -9.
Tu servicio web tiene un shutdown handler. Hace flush de los buffers, cierra conexiones, escribe checkpoints. Lo probaste una vez, tal vez. En producción,…