Software Architect · Módulo 10
En el momento en que el sistema cruza el límite de un solo proceso, aparecen latency, retries, partial failures y una verdad ambigua.
Partial failure · timeout · retry · consistency · CAP
En un sistema distribuido, la falla puede ser parcial: un componente está seguro de que la operación ocurrió, otro todavía no lo sabe.
La red no es una función
Mandar una carta no significa que el destinatario la recibió, la leyó y la entendió. Con la red pasa lo mismo.
Una llamada a un servicio vecino puede terminar en success, timeout, network error o en una respuesta que llega después de que el cliente ya se rindió. El servidor pudo ejecutar la operación, pero el cliente no recibió la respuesta. El cliente pudo hacer retry, y el servidor recibió un duplicado.
Por eso el diseño distribuido necesita timeouts, retries con backoff, idempotency, circuit breakers, correlation ids y líneas claras de responsabilidad. Sin eso, el sistema a veces funciona solo porque la carga es baja.
La consistency cuesta dinero
Puedes sincronizar los relojes de todas las habitaciones de un edificio. Cuanto más grande el edificio, más cara se vuelve la precisión perfecta.
La strong consistency es cómoda para el usuario y para el developer, pero limita availability y latency. La eventual consistency escala mejor y sobrevive a las fallas, pero exige compensaciones, estados pendientes y una UX que sea honesta sobre el estado intermedio.
El arquitecto no debería usar el CAP theorem como un eslogan. Importa más la pregunta concreta: ¿dónde el negocio exige consistencia estricta y dónde se acepta una demora de propagación?
La complejidad de un sistema distribuido aparece en los bordes: dinero, inventory, notificaciones, reporting.
Ejemplo: order y email como garantías distintas
Un recibo importa más que un email de marketing. Perder el recibo es un incidente; perder el email es una molestia.
Crear el pedido y cobrar el dinero tienen que estar estrictamente controlados. La confirmación por email puede pasar por un outbox y un retry worker. Si el email se demora, el pedido sigue siendo válido.
Esa separación de garantías evita meter una distributed transaction donde basta con eventual consistency.
Antiejemplo: una cadena síncrona de siete servicios
Si llegar al trabajo depende de siete ascensores en fila, un ascensor atascado arruina todo el día.
El frontend llama al API, el API llama a checkout, checkout llama a pricing, pricing llama a catalog, después identity, payment, notification. Cada uno con un timeout de 30 segundos. Cuando algo falla, el usuario espera y los ingenieros buscan dónde se rompió exactamente.
Las cadenas síncronas multiplican la latency y la probabilidad de falla. Hay que acortarlas, cachearlas, moverlas a async o diseñarlas con degradation paths explícitos.
- ¿Qué pasa en un timeout después de una ejecución exitosa? - ¿Qué operaciones deben ser idempotentes? - ¿Dónde se necesita strong consistency? - ¿Qué partial failure verá el usuario y cómo lo explica la UI?