Lo que aprendí arquitectando sistemas de pagos globales en Routefusion
Martes, 10:30 de la mañana. Architectural review meeting. Siete personas en la llamada, distribuidas entre Austin, Ciudad de México, Buenos Aires y Londres.
Estamos revisando un diseño para un nuevo flujo de settlement entre dos corredores bancarios. Llevo 20 minutos presentando. En la pantalla compartida hay un diagrama con tres colas, dos servicios, una base de datos transaccional, y flechas que representan compensaciones en caso de falla.
Alguien pregunta: "¿Qué pasa si el servicio B cae después de haber escrito en la cola 2, pero antes de confirmar a la cola 1?"
La pregunta no es hostil. Es curiosidad técnica genuina. Y la respuesta no puede ser "no va a pasar". Porque en un sistema que procesa millones de transacciones por día, "no va a pasar" significa que pasará esta noche.
Esa fue mi vida durante cuatro años. Y esas reuniones — tranquilas, técnicas, sin drama — cambiaron para siempre cómo pienso sobre construir software.
Por qué dejé mi consultora para entrar a una fintech
Antes de Routefusion tenía mi propia consultora. Seis años construyendo productos para clientes en diez industrias distintas — manufactura, construcción, bienes raíces, SaaS, renta de autos, suministros médicos. Más de 50 productos entregados.
Era cómodo. Tenía control. Tenía clientes buenos. Y me estaba quedando corto en un problema específico: la escala.
Los sistemas que construía funcionaban bien para 100 usuarios, 1,000 usuarios, a veces 10,000. Pero nunca había estado en un sistema donde una decisión arquitectónica mal tomada significara perder dinero real a escala de millones.
Quería saber cómo se siente construir infraestructura que simplemente no puede caerse. No por marketing. Por curiosidad técnica.
Routefusion procesa pagos internacionales entre corredores, bancos, y empresas en decenas de países. Un error en un flujo de pagos no es un bug de UX. Es dinero real que se mueve incorrectamente entre cuentas reales en jurisdicciones reales.
Ese contexto — donde cada decisión tiene consecuencias financieras — es donde realmente aprendes arquitectura.
Qué significa "escala" cuando ves los números
Cuando dices "millones de transacciones por día", la gente asiente como si fuera un número abstracto. No lo es.
Significa que tu sistema está procesando transacciones cada segundo. Significa que una latencia adicional de 100 milisegundos en un endpoint se traduce en horas de retraso acumulado al final del día. Significa que si algo falla el 0.01% del tiempo, estás generando cientos de fallas diarias que alguien tiene que resolver.
Significa también que no puedes "probar en producción y ver qué pasa". Porque "qué pasa" puede ser un pago de $50,000 USD mandado a la cuenta equivocada. Y ese pago ya fue ejecutado por el banco. Y recuperarlo puede tomar semanas, abogados, y disculpas al cliente.
Cuando operas a esa escala, la arquitectura no es una preferencia estética. Es supervivencia operativa.
Tres lecciones se quedaron conmigo. Las uso cada semana ahora que construyo MVPs para SMBs. Cambié el contexto, pero los principios siguen valiendo.
Lección 1: La idempotencia no es opcional
En un sistema tradicional, si un usuario hace click dos veces en "enviar", probablemente se envíe dos veces el formulario. Molesto, pero rara vez catastrófico.
En un sistema de pagos, si procesas dos veces la misma transacción porque la red se cayó un segundo y el cliente reintentó — acabas de duplicar un pago de $10,000 USD. Eso no es un bug de UX. Es un problema legal y financiero.
La solución es idempotencia: diseñar cada operación para que se pueda ejecutar múltiples veces con el mismo resultado. Si mando la misma petición tres veces, el sistema ejecuta la operación una sola vez. Las otras dos veces, reconoce que ya se hizo y devuelve el mismo resultado.
Esto requiere diseño deliberado. Claves de idempotencia en cada request. Tablas de historial que registran qué se ejecutó. Lógica que distingue entre "esto es nuevo" y "esto ya pasó y me están preguntando de nuevo".
Por qué esto importa para un SMB
Pensarías que esto solo aplica a fintechs. No es cierto.
Imagina un sistema de inventario para una tienda. El encargado escanea un producto que entró al almacén. La red se cae por dos segundos. Reintenta. Sin idempotencia, ese producto se registró dos veces. Ahora tu inventario dice que tienes 200 unidades cuando en realidad tienes 100.
Al mes siguiente, compras menos porque "ya tienes stock". Te quedas sin producto en temporada alta. Pierdes ventas reales por un bug arquitectónico que nadie notó.
En cada sistema que construyo hoy, las operaciones críticas son idempotentes por default. No porque sea elegante. Porque evita errores silenciosos que destruyen la confianza en los datos.
Lección 2: Observabilidad gana sobre optimismo
En Routefusion había una frase que repetíamos: "No puedes arreglar lo que no puedes ver."
Los sistemas fallan. Eso no es pesimismo, es física. Los servidores caen. Las APIs de terceros devuelven errores raros. Las bases de datos se quedan sin conexiones. La pregunta no es si va a fallar — es qué tan rápido te enteras y qué tan rápido lo arreglas.
La diferencia entre un sistema que sobrevive a fallas y uno que colapsa está en la observabilidad: logs estructurados, métricas en tiempo real, alertas que disparan antes de que los clientes se den cuenta, trazas que te permiten seguir una transacción a través de cinco servicios diferentes.
En la fintech, esto no es negociable. Si no sabes en 60 segundos que un flujo se está cayendo, cientos de transacciones se acumulan sin procesar, y el daño económico empieza a escalar exponencialmente.
Circuit breakers y degradación elegante
Un patrón relacionado: circuit breakers. La idea es simple. Si un servicio externo empieza a fallar, no sigues llamándolo en loop. Detectas el patrón, "abres el circuito", y dejas de enviar peticiones por un tiempo. Eso protege tu sistema de colapsar por dependencias rotas.
Combinado con eventual consistency (no necesitas que todo esté perfectamente sincronizado al milisegundo — necesitas que converja a un estado correcto en una ventana aceptable), estos patrones te permiten construir sistemas que se degradan elegantemente en lugar de colapsar catastróficamente.
Por qué esto importa para un SMB
Aquí es donde la mayoría de las agencias tradicionales fallan a los SMBs. Te entregan un sistema que "funciona" el día del launch, y luego seis meses después alguien te dice "el sistema está raro" — y nadie sabe qué pasó.
Sin observabilidad, estás volando a ciegas. No sabes cuándo se rompió. No sabes por qué se rompió. No sabes qué clientes fueron afectados.
Los sistemas que construyo para SMBs hoy incluyen, desde el día uno:
- Logs estructurados en cada operación crítica
- Alertas automáticas cuando algo se sale del comportamiento esperado
- Dashboards básicos para ver salud del sistema en tiempo real
- Tracing para debugging de flujos complejos
No es sobre-ingeniería. Es lo que separa un sistema mantenible de una caja negra que te aterroriza tocar.
Lección 3: La arquitectura más simple que pueda escalar siempre gana
Esta es probablemente la lección más contraintuitiva.
En una fintech, la tentación de "engineering astronaut" es enorme. Tienes ingenieros brillantes, problemas interesantes, y presupuesto. Es tentador diseñar sistemas que usan los últimos patrones: microservicios para todo, event sourcing, CQRS, arquitecturas hexagonales con cinco capas de abstracción.
Lo que aprendí en Routefusion es lo contrario. La arquitectura correcta es la más simple que pueda manejar la carga actual y la próxima orden de magnitud de crecimiento. No más.
Cada capa de abstracción que agregas es una capa donde pueden esconderse bugs. Cada servicio que separas es una llamada de red que puede fallar. Cada framework exótico que adoptas es un pozo de conocimiento que solo tu equipo tiene.
Los sistemas más confiables que vi operar a escala no eran los más elegantes. Eran los más aburridos. Stack boring. Patrones conocidos. Decisiones técnicas que cualquier ingeniero senior podía entender en 30 minutos de explicación.
La trampa de la complejidad prematura
He visto este patrón muchas veces en SMBs. Una agencia propone una arquitectura de microservicios "para que escale". Seis meses después, el cliente tiene cinco servicios que hablan entre sí, tres bases de datos, un message broker, y un sistema que nadie sabe cómo debugear porque la complejidad está distribuida en todos lados.
¿Y el tráfico real? 200 usuarios al día.
Un monolito bien estructurado hubiera resuelto el mismo problema de negocio en una décima parte del tiempo, con una décima parte del costo operativo, y con la capacidad de evolucionar a algo más complejo cuando realmente se necesite.
La arquitectura más cara no es la que parece cara. Es la que es más compleja de lo que tu problema amerita.
Por qué dejé un rol senior para fundar RASS
Después de cuatro años, tenía una observación incómoda.
El rigor arquitectónico que aplicábamos en Routefusion — idempotencia, observabilidad, circuit breakers, arquitecturas simples y mantenibles — no era exclusivo de las fintechs. Era simplemente buena ingeniería.
Pero ese nivel de rigor casi nunca llega a los SMBs. La mayoría de los negocios pequeños y medianos reciben uno de dos extremos:
- Opción A: Software barato hecho por freelancers junior, que funciona 80% del tiempo y se cae en el peor momento
- Opción B: Software caro hecho por agencias que cobran como si fueran Google pero entregan como si fueran estudiantes
Lo que no existía era un punto medio: ingeniería seria, principios probados a escala real, aplicados a los problemas específicos de SMBs — y entregado en un timeline realista para un negocio que no tiene 6 meses y $200K USD para esperar.
Esa es la tesis de RASS. No es que SMBs necesiten menos ingeniería. Es que necesitan la misma calidad, aplicada con enfoque.
La velocidad es la única ventaja competitiva real para una startup. Pero la velocidad sin rigor es deuda técnica disfrazada de productividad.
Cómo aplicar estas lecciones a un SMB
Cada vez que arranco un proyecto nuevo, me hago las mismas tres preguntas que hacíamos en los reviews arquitectónicos de Routefusion:
1. ¿Qué pasa si esta operación se ejecuta dos veces?
Si la respuesta incluye "un problema", necesito idempotencia. Da igual si es un sistema de inventario para una ferretería o un tracker de clientes para un consultorio dental. Los mismos principios aplican.
2. ¿Cómo me entero si esto se rompe?
Si la respuesta es "cuando el cliente me llame enojado", no es suficiente. Necesito logs, alertas, y visibilidad básica desde el día uno.
3. ¿Es esta la arquitectura más simple que resuelve el problema?
Si hay un patrón más exótico, lo descarto a menos que haya una razón concreta. La complejidad debe ganarse, no asumirse.
Esas tres preguntas son la herencia de cuatro años arquitectando sistemas de pagos. Y son, creo, la diferencia entre un MVP que sobrevive sus primeros 1,000 usuarios y uno que hay que reescribir antes del cliente 100.
Si quieres ver cómo esto se aplica al timeline de 30 días, escribí sobre el proceso completo aquí. Los principios no se comprometen por la velocidad — se comprometen por el scope.
Una conversación, no una venta
Este post es distinto a los otros que escribo. No estoy tratando de convencerte de nada. Estoy compartiendo lo que aprendí en un momento específico de mi carrera, y cómo esas lecciones cambiaron mi forma de construir software.
Si este enfoque a la ingeniería resuena con cómo piensas sobre tu negocio, quizás valga la pena una conversación. No para venderte — para entender si tu proyecto es uno donde este nivel de rigor puede marcar una diferencia real.
Agenda una Discovery Call gratuita →
30 minutos. Sin compromiso. Si tu proyecto no es el indicado para este modelo, te lo digo de entrada.
Sobre el autor: Ramm Alvarez es un Solutions Architect con más de 10 años de experiencia. Durante 6 años tuvo su propia consultora de software, donde construyó más de 50 productos para 10 industrias diferentes. Los últimos 4 años los pasó como Senior Software Engineer en startups de Estados Unidos, más recientemente arquitectando sistemas de pagos globales en Routefusion. Hoy dirige RASS, un estudio de desarrollo que entrega MVPs listos para producción en 30 días.
