Un arquitecto civil nunca se pregunta "¿cómo evito un terremoto?" Sabe que es imposible. La pregunta real es: ¿cómo diseño para que el edificio sobreviva?

Cimientos flexibles. Amortiguadores sísmicos. Secciones aisladas. No evita el movimiento. Lo absorbe. En el software pasa exactamente igual.

Bola de acero en el edificio Taipei 101

Bola de Acero en el Edificio Taipei 101

730 toneladas de acero suspendidas en el piso 87. No evita el terremoto. Lo absorbe.

Tu arquitectura debería hacer lo mismo.

Diseñar sistemas que funcionan es fácil, sistemas que resisten, no tanto

Después de más de 20 años diseñando arquitecturas en diferentes tipos de organizaciones, el mismo patrón se repite:

  • Equipos que invierten millones en infraestructura redundante
  • Servidores replicados
  • Backups automáticos
  • Múltiples zonas de disponibilidad

Y cuando llega el fallo real… todo cae junto, como un castillo de naipes.

¿Por qué?

Porque redundancia ≠ resiliencia.

Redundancia = tener copias. Si algo falta, tienes respaldo.

Resiliencia = el sistema sigue funcionando aunque algo falle. Degrada, pero no colapsa.

Es la diferencia entre un edificio con paredes gruesas y uno con amortiguadores sísmicos.

La resiliencia como requisito no funcional

El punto de quiebre fue aplicar ISO/IEC 25010 no como checklist, sino como lenguaje de diseño.

Define cuatro cosas que deberían ser requisitos desde el día cero:

  • Confiabilidad: ¿cuántas transacciones se completan correctamente?
  • Disponibilidad: ¿cuánto tiempo puedo estar fuera de servicio? (RTO)
  • Tolerancia a fallos: cuando algo falla, ¿el resto continúa?
  • Recuperabilidad: ¿cuántos datos pierdo? (RPO)

Cuando estas conversaciones dejan de ser técnicas y se convierten en "¿cuánto nos cuesta cada minuto de downtime?", el negocio escucha diferente.

Diseñar pensando en el fallo

Un desarrollador piensa "esperemos que esto no se caiga". Un arquitecto debe pensar en "construyamos un sistema resiliente y midamos su resistencia real".

Eso cambia todo:

  • Decisiones justificadas por números, no por intuición
  • Equipos alineados en el "por qué"
  • Arquitecturas que aguantan presión real porque están preparadas para soportar imprevistos, no para evitarlos