Respuesta.

En la historia del desarrollo de sistemas de TI distribuidos, las cuestiones de manejo de errores y escenarios de fallos han estado en un segundo plano durante mucho tiempo, cediendo espacio a la lógica de negocio. Sin embargo, el crecimiento en la escala y la complejidad de la infraestructura ha demostrado con el tiempo que los escenarios de manejo de errores no desarrollados conducen a fallos masivos y pérdidas de datos.

El problema radica en que los sistemas complejos experimentan muchos tipos de fallos: desde la indisponibilidad de servicios individuales hasta la inconsistencia de datos o fallos parciales en canales de comunicación. A menudo, los clientes entienden por "fallos" solo los errores evidentes (por ejemplo, un servidor no disponible), ignorando las cadenas de errores entre servicios o la degradación de la experiencia del usuario.

Una solución efectiva se basa en un enfoque sistemático:

Detección de todos los posibles puntos de fallo.
Desarrollo de escenarios exhaustivos para su aparición junto con arquitectos, QA, diseñadores y ingenieros de explotación.
Coordinación del comportamiento del sistema con el negocio (por ejemplo, si se pueden retrasar pedidos o si se requiere almacenar en caché operaciones).
Documentación clara de todos los tipos de mensajes de error y rutas de manejo.

Características clave:

Manejo no solo de fallos fatales, sino también de fallos suaves/fluctuantes (por ejemplo, la indisponibilidad temporal de un servicio externo).
Inclusión de escenarios de degradación de la UI y funcionalidad.
Delimitación de errores de negocio y fallos técnicos en todas las etapas de elaboración de requisitos.

Preguntas con truco.

¿Cuál es la diferencia entre una excepción a nivel de aplicación y a nivel de infraestructura?

Con frecuencia, los candidatos confunden errores de negocio (por ejemplo, "usuario no encontrado") con fallos reales (por ejemplo, "base de datos no disponible"). La aplicación siempre debe distinguir claramente entre los dos tipos de excepciones y proporcionar diferentes estrategias de manejo (reversión, notificaciones, alertas).

¿Qué escenarios de fallo deben modelarse para una API interna, si no es pública?

Los escenarios de fallo son relevantes para cualquier API: incluso si la API es interna, los fallos siempre son posibles (incluso dentro de un mismo contorno de automatización), y deben modelarse explícitamente para trabajar correctamente con datos inexactos/ausentes.

¿Debería el sistema ocultar todos los errores al usuario por el bien de la máxima experiencia de usuario?

No, ocultar absolutamente los errores conduce a la desinformación del usuario. Es importante encontrar un equilibrio entre la informatividad (para que el usuario entienda qué hacer a continuación) y la seguridad (sin revelar detalles de implementación).

Errores comunes y anti-patrones

Manejo no formalizado de fallos (dejados en "por defecto" en los catch).
Ausencia de escenarios de degradación en caso de fallos parciales (en el caso de microservicios: un carrito no funcional bloquea completamente la realización de pedidos).
Ignorancia del acumulamiento de "fallos silenciosos" (sin alertas/monitoreo sobre situaciones excepcionales).

Ejemplo de la vida

Caso negativo: En un gran proyecto de e-commerce, un analista de sistemas dejó el manejo de todos los errores de red a la arquitectura. Durante actualizaciones de emergencia y fallos en el servicio de correo, el sistema no enviaba notificaciones de pedidos, y los usuarios no entendían si sus pedidos habían sido creados.

Ventajas:

Simplificación de la descripción de requisitos.

Desventajas:

Pérdida de datos (imposible probar la creación de un pedido).
Los costos de soporte aumentaron después del lanzamiento del producto.

Caso positivo: El analista de sistemas junto con el arquitecto modelaron escenarios individuales para cada servicio crítico: indisponibilidad de la cola de correos, caídas de pasarelas de pago, degradación del servicio de búsqueda. Se redactaron mensajes amigables para los usuarios.