El optimismo ciego es negligente, pero el pesimismo extremo es una receta perfecta para la parálisis.
El mito del "Mundo Ideal"
Casi todo en el software se basa en instancias donde todo funciona "según lo planeado": las redes no fallan, los datos son perfectos y los procesos no tienen desviaciones. Pero la realidad nos supera:
- Datos sin máscara de ingreso.
- Personas sin segundo nombre.
- ISBN con códigos incorrectos.
Prever cada error es imposible; toma tiempo y recursos que no tenemos. Quizás la fórmula mágica sea generar caídas inteligentes.
Degradación controlada y UX
Debemos construir momentos donde el sistema identifique que no puede seguir y ejecute una caída de emergencia controlada. No es lo mismo un "Error interno" que explicarle al usuario qué validar para que su aterrizaje sea tranquilo.
Si el sistema falla, que sea una degradación controlada que nos permita medir el problema y solucionarlo rápido.
Menos reglas, mejores cimientos
Un sistema no es mejor por tener 10 capas de validación que lo vuelven inutilizable. Se trata de tener las reglas correctas para operar con confianza ante la incertidumbre.
¿En tu equipo están invirtiendo tiempo en prevenir lo imposible o en ser resilientes para cuando lo inevitable ocurra?
Publicado originalmente en LinkedIn
Imagen creada con IA
Top comments (2)
El punto sobre resiliencia vs perfección toca algo que veo constantemente en sistemas distribuidos: la gente diseña el happy path y trata los errores como ciudadanos de segunda clase. En mi trabajo con workflows de aprobación usando BullMQ, aprendí que los estados de fallo necesitan tanto diseño como los estados de éxito — dead letter queues, reintentos con backoff exponencial, alertas. Un sistema que no sabe fallar de forma predecible es más peligroso que uno que falla seguido. ¿Hasta dónde llegás vos en el diseño de los failure paths antes de hacer deploy?
Hola, siempre indico al equipo que debemos validar por capas y las pruebas unitarias de cada capa. En estas formas de pensar hay que sumar lógica de observabilidad del proceso, es decir, poder observar la tasa de errores e investigar según registros de errores (Cloudwatch, Sentry...) qué tipo de errores aparecen y cómo se produjeron en producción.
En ocasiones en sistemas distribuidos cuesta hacer seguimiento del error ya que vemos el input, pero el output se pierde en el camino y ahí cobra importancia la observabilidad del proceso.
Son ideas nada más, pero me queda claro, por tu comentario, que la programación defensiva, como se denomina este patrón, es siempre el primer recaudo que debemos pensar: las happy paths son expresiones del dominio optimista del dueño del proceso, pero no nuestro dominio, que debemos pensar un poco más allá.
Gracias por el mensaje =)