System Design
Explica cómo diseñar disponibilidad, tolerancia a fallos, degradación, redundancia, backups, failover y recuperación mediante SLOs, RPO y RTO.
Un sistema resiliente no evita todos los fallos: limita su alcance, mantiene funciones esenciales y recupera un estado correcto con evidencia.
Disponibilidad mide si una capacidad puede utilizarse. Resiliencia describe cómo el sistema absorbe y aísla fallos. Recuperación define cómo restablece servicio y datos después de una interrupción.
En sistemas distribuidos, una dependencia puede estar lenta, responder parcialmente o fallar mientras otras continúan sanas. Sin límites, retries, pools compartidos y colas crecientes convierten un fallo local en una caída general.
fallo esperado
→ detectar
→ limitar propagación
→ degradar o fallar rápido
→ conservar estado recuperable
→ restaurar
→ verificar y aprenderNo todo el sistema tiene la misma criticidad. Puede ser válido que recomendaciones fallen mientras checkout sigue operativo.
Define por capacidad:
Una llamada remota puede:
Diseñar solo “éxito o excepción” ignora estados reales.
Toda operación remota necesita límite. Un timeout debe considerar:
Un timeout demasiado alto consume recursos; uno demasiado bajo genera falsos fallos y retries.
Reintenta solo errores transitorios y cuando la operación es segura o idempotente.
Buenas prácticas:
Retry-After.No reintentes validaciones, permisos o errores permanentes.
Una dependencia lenta provoca timeouts. Cada cliente reintenta y multiplica la carga, reduciendo aún más la capacidad.
Mitigaciones:
Estados típicos:
No sustituye timeout, fallback ni monitoreo. Un breaker global puede ocultar que solo una operación o tenant falla.
Aíslan recursos para que un flujo no consuma todo:
La separación añade capacidad reservada y configuración, pero evita cascadas.
Cuando el sistema está saturado, rechaza trabajo menos prioritario antes de colapsar.
Ejemplos:
Es preferible un rechazo controlado a mantener miles de solicitudes bloqueadas.
Una función alternativa debe preservar la intención principal.
recomendaciones caídas
→ mostrar productos populares cacheadosUn fallback incorrecto puede ser peor que fallar, especialmente en pagos, precios o permisos.
Tener varias instancias ayuda solo si no comparten el mismo punto de fallo. Revisa:
Dos réplicas en el mismo host no protegen contra fallo del host.
Tiempo objetivo para restaurar una capacidad.
Cantidad máxima de datos que puede perderse medida en tiempo.
RTO = 1 hora
RPO = 15 minutosEstos objetivos condicionan backups, replicación, runbooks y coste. No se definen de forma genérica para todo el sistema.
Son controles complementarios.
Un backup solo es útil si puede restaurarse dentro del RTO y producir datos íntegros.
Debe verificarse:
Decide:
Failover automático no siempre es mejor; una detección incorrecta puede causar dos primarios o pérdida.
Después de un fallo, el sistema suele repetir operaciones. Claves de idempotencia, versiones y registros de procesamiento permiten recuperar sin duplicar cobros, pedidos o movimientos.
Cuando no se conoce el resultado de un sistema externo:
payment = unknown
→ consultar proveedor
→ comparar con estado local
→ confirmar, compensar o escalarLos estados inciertos deben existir en el modelo; esconderlos como error genérico impide recuperación.
Dependencias:
Diseño:
pending_payment o payment_unknown cuando corresponda.Reduce impacto de una zona. Requiere que datos, balanceo y dependencias también toleren la pérdida.
Puede mejorar recuperación regional o latencia, pero añade replicación, routing, consistencia, operación y coste. Debe justificarse por RTO/RPO o negocio.
Se producen cuando:
El diseño debe modelar capacidad y límites durante fallo, no solo durante estado sano.
Prueba hipótesis de manera controlada:
Empieza en entornos seguros y con criterios de abortar. El objetivo es aprender, no causar caos por espectáculo.
Un runbook útil indica:
Debe probarse y mantenerse, no existir solo como documento.
Puede agotar recursos más rápido que un error inmediato.
La compensación también necesita retry e idempotencia.
Base recuperada, pero objetos o eventos faltan. Verifica el sistema completo.
Failover puede perder escrituras recientes según RPO.
Dos nodos aceptan escrituras y divergen. Requiere fencing y coordinación.
Código, esquema y eventos deben ser compatibles con el punto restaurado.
Mayor disponibilidad suele aumentar coste, complejidad y operación. No todas las funciones necesitan la misma redundancia. Una arquitectura más simple y bien recuperable puede ser mejor que una topología altamente distribuida que el equipo no puede operar.
Observabilidad y operación define las señales necesarias para detectar impacto, diagnosticar causas y ejecutar recuperación.