La mayoría de los sistemas distribuidos no fallan por una caída dramática. Fallan porque una pequeña suposición se mantuvo durante dos años y de pronto dejó de ser cierta. Una llamada de red que suele tardar 40 ms empieza a tardar tres segundos. Una política de reintentos que debía ser una red de seguridad termina de rematar a una dependencia que ya estaba sufriendo.
La resiliencia tiene menos que ver con evitar fallos y más con hacer que los fallos sean aburridos.
Empieza por los modos de fallo
Antes de elegir un patrón, escribe qué ocurre realmente cuando cada dependencia se comporta mal. Solo hay unas pocas formas que vale la pena nombrar:
- Lenta: la llamada responde, pero tarda lo suficiente para agotar el pool de conexiones.
- Caída: la llamada falla rápido y con claridad.
- Intermitente: funciona con la frecuencia suficiente para que nadie construya un fallback.
- Envenenada: la misma entrada defectuosa produce el mismo error costoso una y otra vez.
Cada una necesita una respuesta distinta. Los timeouts ayudan con lo lento. Los circuit breakers ayudan con lo caído y lo intermitente. Las claves de idempotencia y las colas de mensajes muertos ayudan con lo envenenado. Aplicar reintentos a los cuatro es cómo convertir un incidente pequeño en uno regional.
Los timeouts son una decisión de diseño
Un timeout no es un número que se copia de una plantilla. Es una afirmación sobre cuánto está dispuesto a esperar tu usuario y cuánto trabajo estás dispuesto a abandonar. Presupúestalo explícitamente: si el borde tiene 800 ms, la capa de orquestación tiene 500 ms y el servicio hoja tiene 200 ms. Cada capa que inventa su propio timeout rompe el presupuesto.
Haz explícita la recuperación de estado
Los sistemas basados en eventos tienden a esconder su historia de recuperación. Haz tres preguntas:
- Si este consumidor procesa un mensaje dos veces, ¿qué se rompe?
- Si se cae a mitad de una transacción, ¿quién repara el estado?
- Si la cola se atrasa una hora, ¿qué ve el usuario?
Si la respuesta a cualquiera es “probablemente no pase”, el diseño no está terminado. Manejadores idempotentes, un patrón outbox para escrituras y un log de eventos reproducible cubren casi todo el hueco sin añadir mucha ceremonia.
Observa el sistema que tienes
Los dashboards no son observabilidad. Una señal útil responde la pregunta que alguien hace a las 2 de la mañana: qué dependencia está lenta, qué inquilino está afectado y si el sistema se está recuperando. Mide saturación, presupuestos de error y profundidad de cola por servicio, no solo CPU.
El objetivo no es cero incidentes. Es que los incidentes se queden pequeños, se recuperen sin heroísmos y te enseñen algo después.