Diseñar para el fallo, no para el happy path

Cuando todo anda bien, cualquier sistema parece bien diseñado. La diferencia se ve cuando UNA pieza se cae: ¿el sistema entero muere, o degrada gracefully y sigue siendo útil?

Regla de Orbit: un sistema bien diseñado falla con dignidad. El usuario recibe algo útil incluso cuando una pieza interna está rota. Mal diseñado: el usuario ve un 500 cuando la analítica secundaria estaba colgada.

Los cuatro modos de degradación

1. Rutear al default seguro

Cuando el sistema no puede decidir (clasificador caído, router perdió contexto), la única salida sensata es escalar a humano. Forzar una decisión sin info es invitar un mis-routing silencioso.

2. Responder explicitando la limitación

Cuando falta un dato pero podés responder parcialmente, devolvé lo que sí tenés y declará qué falta. "No pude consultar el roster del viernes, pero acá está el del jueves" es infinitamente mejor que "no sé" o "[inventando un roster que no es]".

3. Saltar el paso y seguir

Cuando el paso es opcional o no crítico, el sistema lo skipea y sigue. Enrichment, recomendaciones cosméticas, telemetría que decora la respuesta. cualquier cosa que no afecta el output principal puede irse sin ruido.

4. Loguear y degradar silenciosamente

Cuando el fallo es post-respuesta o de housekeeping, no se lo cuentes al usuario. El user ya recibió valor; loguear para fix interno y seguir. Notificaciones secundarias, métricas, follow-up que falla. logueás, alertás al oncall si corresponde, no rompés la experiencia.

Qué NO hacer

• Fail-stop al primer error. Una pieza secundaria falla y el sistema entero devuelve 500. Es lo más fácil de implementar y lo peor para el usuario.
• Fail-silent invisible al usuario. El sistema dice "OK, listo" pero faltó la mitad del trabajo. Peor que fallar visiblemente: el usuario cree que tiene algo que no tiene.
• Degradar todo siempre. Si tu sistema responde "no pude" demasiado seguido, perdés credibilidad. Degradación es la excepción, no la rutina.

El test mental

Para cada subsistema preguntate: si esta pieza falla, ¿qué es lo "menos malo" que el sistema puede hacer?. Esa respuesta es tu modo de degradación. Escribilo en el diseño antes de que pase.

classifier_down  → route to escalate (mejor: humano)
rag_empty        → answer with disclaimer
roster_api_down  → answer with disclaimer
enrichment_slow  → skip (no es crítico)
notify_fails     → log + alert (user ya tiene valor)

El usuario no se entera de cuántas piezas internas tienen problemas en un día. Se entera de cuántas veces el sistema fue inútil. Las dos cosas pueden no estar correlacionadas. depende de cómo diseñes la degradación.

Tu ejercicio

A la derecha, cinco fallos posibles del Watch Officer Assistant. Conectá cada fallo a su modo correcto de degradación. Cuando el grafo esté completo, tenés diseñada la mitad invisible del sistema. la mitad que decide si tu sistema sirve o no en producción.