Asumir que funciona
El error se trata como una excepción a manejar. La recuperación es un parche que se agrega al final, cuando ya hay un incidente.
Los sistemas fallan.
Hay que asumirlo.
El fallo no es un accidente que evitar: es la condición normal de cualquier sistema que opera en el mundo real. Asumimos la entropía como punto de partida y diseñamos, desde la base, para detectarla, resistirla y recuperarnos solos.
La realidad
La entropía no es un bug.
La entropía no es un bug.
Es la segunda ley.
Todo sistema tiende al desorden. El software no es la excepción: cuanto más crece, más superficies tiene para fallar, y más probable es que algo —en algún punto— deje de funcionar como esperabas. No es mala praxis. Es física aplicada a la operación.
Redes
Latencia, cortes y paquetes perdidos entre dos servicios que deberían hablarse.
APIs externas
Caídas, límites de rate y cambios de contrato sin aviso previo.
Servidores
Se reinician, se quedan sin memoria, se saturan bajo carga.
Modelos de IA
Responden distinto, alucinan, cambian de versión o se ponen lentos.
Datos
Llegan incompletos, duplicados, fuera de orden o directamente corruptos.
Personas
Un deploy a destiempo, una credencial vencida, un clic equivocado.
El espejismo
Casi todo se diseña
Casi todo se diseña
para el camino feliz.
El patrón habitual es construir asumiendo que todo va a salir bien —y recién después, si queda tiempo, agregar el manejo de errores como una capa encima.
El resultado es software que funciona perfecto en la demo y se desarma en producción, donde el camino feliz es la excepción, no la regla. La confiabilidad termina dependiendo de reintentos manuales, scripts frágiles y alguien de guardia a las tres de la mañana.
La pregunta no es si tu sistema va a fallar.
Es qué pasa cuando lo haga.
Casi todos los desarrollos contestan la primera pregunta. Nosotros diseñamos para responder la segunda.
Nuestra postura
El enfoque habitual
Nuestro enfoque
Invertimos el supuesto.
Asumir que va a fallar
La recuperación se diseña primero. La resiliencia es parte de la arquitectura desde el día cero, no un agregado posterior.
No diseñamos para que nada falle. Diseñamos para que el fallo no importe.
Resiliencia en dos capas
Sobrevivir a la caída
Pasiva · ejecución durable
Activa · auto-sanación
El detalle técnico, en Temporal →
Sobrevivir a la caída
y recuperarse de ella.
El trabajo no se pierde
Cada proceso corre como workflow con estado persistente. Si cae un worker, una API o un modelo, se reanuda exactamente donde quedó, sin reprocesar lo ya hecho.
El sistema se cura solo
Sobre esa base instalamos monitoreo de salud y recuperación automática: el sistema detecta el fallo, reinicia los componentes afectados y vuelve a operar sin intervención manual.
Lo que implica, en concreto
Los principios que aplicamos
Los principios que aplicamos
en cada desarrollo.
01
Idempotencia
Repetir una operación no duplica su efecto. Un reintento nunca cobra dos veces ni emite dos comprobantes.
02
Aislamiento de fallos
Cada componente vive en su propio compartimento: el que cae no arrastra a los demás.
03
Reintentos con backoff
Ante un fallo transitorio reintentamos con espera creciente, sin saturar al servicio que ya está sufriendo.
04
Circuit breakers
Cuando un servicio externo se cae, cortamos el flujo hacia él y lo dejamos recuperarse, en vez de insistir hasta arrastrar todo.
05
Degradación elegante
Si una pieza no responde, el sistema sigue operando con funciones reducidas en lugar de caerse entero.
06
Health checks y auto-restart
Vigilamos la salud de cada servicio y reiniciamos automáticamente lo que deja de responder.
07
Backups con restore probado
No alcanza con respaldar: probamos la restauración. Un backup que nunca se restauró no es un backup.
08
Observabilidad
Si no se ve, no se puede recuperar. Trazas, métricas y logs para detectar el fallo antes de que escale.
Lo que cambia para vos
Resiliencia que se siente
Resiliencia que se siente
en la operación.
Menos caídas visibles
Los fallos transitorios se resuelven antes de impactar al usuario o al cliente.
Recuperación desatendida
El sistema vuelve a un estado sano sin esperar a que alguien esté disponible para reiniciarlo.
Continuidad operativa
Los procesos críticos siguen corriendo aunque el entorno se degrade de forma temporal.
Menos costo de operación
Menos horas del equipo dedicadas a reprocesar a mano y apagar incendios.
No es teoría
Ya corre en producción.
Suite ARCA se auto-sana ante las caídas de AFIP: encola lo que falla, lo deduplica por huella criptográfica y lo reintenta solo, en franjas nocturnas, sin intervención. DocuMed y Graphity operan sobre la misma base durable. Y todo lo que entregamos corre sobre Temporal —nuestra capa de ejecución durable.
La promesa
No prometemos que nada falle. Garantizamos que, cuando falle, el sistema siga en pie.
¿Cómo se comporta tu sistema el día que algo se rompe? Esa es la conversación que nos interesa.