Arquitectura ajolote: cuando regenerar sale más barato que tener réplicas
En junio de 2026 perdí mis dos nodos primarios al mismo tiempo, por más de 50 horas seguidas. No hice failover. Regeneré.
Opero un stack no-trivial sin equipo de SRE detrás. Cuando se cayó, aprendí de manera empírica que el patrón de resiliencia que ya tenía no era alta disponibilidad, no era failover, y no necesitaba serlo. Le terminé poniendo nombre: arquitectura ajolote.
La metáfora
El ajolote es una salamandra mexicana que regenera extremidades, médula espinal, partes del corazón. No es inmortal: si le quitas el oxígeno se muere igual. Lo que tiene es que si pierde un brazo, el cuerpo lo re-crece desde el tejido. La identidad del animal no vive en el brazo. Vive en el genoma.
Aplicado a un stack, son tres decisiones:
No hay alta disponibilidad. No mantengo réplicas vivas de cada servicio esperando su turno. Para decenas de servicios eso es un costo operativo permanente que no puedo absorber.
No hay failover automático. Un health check con falso positivo —un reboot legítimo de cinco minutos— dispara un switch que después cuesta horas de reconciliación manual. Pulsar el switch a mano cuesta dos minutos. Prefiero pagar los dos minutos.
Sí hay regeneración deliberada. Cuando pierdes un nodo, lo vuelves a crecer. Lo que hace eso posible es el substrate: código versionado fuera del nodo, respaldos offsite frescos y un workspace replicado. Ahí vive la identidad del sistema.
Los nodos son intercambiables. Un servidor no es la base de datos: es el contenedor donde corre hoy. Si muere, la levanto en otro lado desde el respaldo.
El trade-off
El ajolote no es magia. No te salva de perder el substrate — si eso pasa, no había manera. Lo que hace es desacoplar “cuántos nodos sobreviven” de “qué tan rápido vuelvo a estar vivo”.
En la práctica fueron unas horas de trabajo nocturno para tener en línea de nuevo la mayor parte de lo que opero, y cero pérdida de datos cuando el primary regresó. El primary y el ajolote no compiten: son capas.
El cálculo es de costo recurrente. Mantener réplicas vivas se paga todos los días. Mantener el substrate sano —respaldos que corren, sincronización que no se salta nada, el patrón documentado— se paga una vez y se revisa de vez en cuando.
Cuándo no aplica
No es bala de plata. Hay tres escenarios donde la regeneración deliberada es mala respuesta:
SLA externo estricto. Si firmaste 99.99% (52 minutos al año), no te alcanza un RTO medido en horas. Necesitas réplicas activas, anycast, multi-región.
Latencias estrictas. Si tienes que responder en milisegundos de forma consistente, no puedes meter una capa de “y si esto cae, regenero”. Necesitas activos calientes y health checks rápidos.
Divergencia de datos inaceptable. En banca, ledger contable estricto o cualquier sistema con concurrencia de escritura alta, un RPO de horas no es opción. Necesitas log-shipping y replicación síncrona.
Para todo lo demás —que en mi experiencia es la mayoría de los stacks personales y de startups en etapa temprana— el ajolote gana en costo/beneficio.
Cierre
La resiliencia no se compró con redundancia. Se compró con substrate sano. Mientras el código esté versionado fuera del nodo, los respaldos estén frescos y el workspace viva en más de un lugar, cualquier nodo es desechable. Los nodos son contenedores temporales del sistema; el sistema vive en otro plano.
El ajolote regenera porque su identidad no vive en la extremidad.