Arquitectura de Software Escalable para Fintech: Cómo Evitar el Colapso

En cada proyecto de software existe una decisión que casi nunca aparece en las reuniones de ventas, raramente se menciona en las cotizaciones, y que sin embargo determina todo lo que viene después: la arquitectura.

No el color de los botones. No el framework de moda. La arquitectura: cómo se divide el sistema en partes, cómo esas partes se comunican entre sí, dónde viven los datos, y quién es responsable de qué.

Una arquitectura bien diseñada es invisible — el sistema simplemente funciona, crece y se adapta. Una arquitectura mal diseñada es muy visible: cada nueva funcionalidad tarda el doble de lo esperado, cada cambio rompe algo en otro lado, y llegado cierto punto el equipo de desarrollo pasa más tiempo apagando incendios que construyendo cosas nuevas.

En el sector fintech, donde los sistemas manejan dinero real, datos regulados y transacciones que no pueden fallar, una arquitectura deficiente no es solo un problema técnico. Es un riesgo de negocio.

El error más común: el monolito disfrazado

La mayoría de sistemas que llegan a Ab4cus para ser rediseñados tienen el mismo patrón: empezaron como algo pequeño y manejable, y con el tiempo se convirtieron en lo que los arquitectos llaman un big ball of mud — una masa de código donde todo depende de todo, nadie entiende exactamente qué hace cada parte, y cambiar cualquier cosa requiere probar todo.

El monolito no es inherentemente malo. Para un MVP o un sistema pequeño, un monolito bien estructurado es perfectamente válido — es más simple de desplegar, depurar y mantener. El problema es cuando el monolito crece sin estructura interna: sin separación de responsabilidades, sin límites claros entre módulos, sin una lógica que diga "este código pertenece a este dominio y no puede depender de ese otro".

Ese es el momento en que agregar un módulo de compliance AML a un sistema de pagos existente se convierte en un proyecto de seis meses en lugar de seis semanas.

Domain-Driven Design: la filosofía que hace que el código hable el idioma del negocio

En Ab4cus organizamos el código siguiendo los principios de Domain-Driven Design (DDD), una metodología de diseño de software que parte de una premisa simple pero poderosa: el código debe reflejar el negocio, no al revés.

En la práctica, esto significa dividir el sistema en bounded contexts — dominios de negocio claramente delimitados, cada uno con su propio modelo de datos, su propia lógica y sus propias reglas. Para una plataforma fintech típica, esos dominios pueden ser:

• Identidad y onboarding — Todo lo relacionado con crear, verificar y gestionar la identidad del ciudadano/cliente
• Compliance KYC/AML — El motor de reglas, el scoring de riesgo, los reportes regulatorios
• Pagos y transacciones — El procesamiento, la conciliación, el historial
• Notificaciones — Emails, SMS, push notifications — completamente desacopladas del resto
• Administración y backoffice — Los dashboards internos del equipo operativo

Cada uno de estos dominios puede evolucionar de forma independiente. Si el regulador cambia los requisitos de reporte AML, se modifica el dominio de compliance — sin tocar los pagos ni el onboarding. Si se agrega un nuevo proveedor de pagos, se modifica el dominio de pagos — sin riesgo de romper la lógica de KYC.

Esta independencia es lo que permite a un equipo de cinco personas trabajar en paralelo en cinco módulos diferentes sin pisarse entre sí — y a la empresa agregar funcionalidades en semanas en lugar de meses.

Cuándo tiene sentido hablar de microservicios (y cuándo no)

Los microservicios son el tema más mal entendido de la arquitectura de software en LATAM. Muchas agencias los venden como sinónimo de "arquitectura moderna" sin explicar el costo real que implican.

La realidad es más matizada:

Los microservicios tienen sentido cuando:

• El equipo de desarrollo es suficientemente grande para tener equipos separados por servicio (mínimo 15-20 personas)
• Los dominios del sistema tienen requerimientos de escala radicalmente diferentes (el módulo de notificaciones necesita procesar 1 millón de eventos por hora; el módulo de backoffice procesa 50 operaciones por día)
• Diferentes partes del sistema tienen ciclos de deploy independientes y frecuentes
• El presupuesto de infraestructura justifica la complejidad operativa adicional

Los microservicios NO tienen sentido cuando:

• El equipo tiene menos de 10 desarrolladores
• El sistema está en etapa temprana y los dominios aún están cambiando
• No hay un equipo DevOps dedicado a gestionar la complejidad de orquestación (Kubernetes, service mesh, distributed tracing)
• El cliente asume que microservicios = más rápido o más barato — exactamente al contrario

Criterio	Monolito Modular (Recomendado)	Microservicios (Solo si es necesario)
Tamaño del Equipo	Menos de 10-15 desarrolladores	Equipos grandes (15+ personas)
Complejidad Operativa	Baja / Media (Fácil de desplegar)	Muy Alta (Kubernetes, DevOps dedicado)
Escalabilidad de dominios	Todo el sistema escala junto	Los módulos escalan de forma independiente
Etapa del Proyecto	MVP o fase de crecimiento temprano	Sistema maduro con dominios estables

En Ab4cus usamos una arquitectura intermedia que da los beneficios de la modularidad sin la complejidad operativa de los microservicios puros: un monolito modular con bounded contexts bien definidos, que puede descomponerse en servicios independientes cuando el negocio lo justifique. Es el mismo código, la misma lógica de dominio — pero con la flexibilidad de desplegar de forma separada si es necesario.

La arquitectura de datos: el error que más cuesta corregir

Si la arquitectura de código es importante, la arquitectura de datos es crítica. Especialmente en fintech, donde los datos son el activo más valioso y el más regulado.

En Ab4cus organizamos los datos en schemas separados por dominio dentro de PostgreSQL. El schema de compliance tiene sus tablas. El schema de pagos tiene las suyas. Nunca un JOIN directo entre dominios — si un dominio necesita datos de otro, pasa por la capa de aplicación, donde la lógica de negocio puede aplicar las reglas correctas.

Esto tiene tres consecuencias prácticas enormes:

Seguridad granular — Con Row Level Security de PostgreSQL, podemos definir que el módulo de compliance solo puede ver los datos de compliance, aunque esté en la misma base de datos. No hay riesgo de que una consulta mal escrita en el módulo de pagos exponga datos regulados de KYC.

Auditoría completa — Cada cambio en datos sensibles pasa por triggers de base de datos que registran quién cambió qué, cuándo, y desde qué estado anterior. En una auditoría regulatoria, eso es la diferencia entre responder en horas o en semanas.

Migraciones controladas — Con Flyway, cada cambio al esquema de base de datos es un archivo versionado que se aplica en orden y se puede revertir. Nunca más "alguien cambió la base de datos directamente en producción y nadie sabe qué cambió".

Cómo evaluar la arquitectura antes de contratar

Si está evaluando a un proveedor de software, estas preguntas revelan rápidamente la madurez arquitectónica del equipo:

• ¿Cómo organizan los módulos del sistema internamente? — Si la respuesta es vaga o "por carpetas", es una señal de alerta.
• ¿Cómo manejan los cambios de esquema de base de datos entre versiones? — Si no mencionan migraciones versionadas, es un problema.
• ¿Cómo garantizan que un cambio en el módulo A no rompa el módulo B? — Si no tienen pruebas automatizadas y contratos de API definidos, el sistema se va a volver frágil.
• ¿Cómo escala el sistema si el volumen de transacciones se multiplica por diez? — Si la respuesta es "agregamos más servidores", preguntar si la arquitectura fue diseñada para eso.
• ¿Qué pasa con el código si dejamos de trabajar con ustedes? — La respuesta correcta es que el código está documentado, los estándares son de la industria, y cualquier desarrollador senior puede continuarlo.

La arquitectura no es un gasto — es una póliza de seguro

El costo de una buena arquitectura se paga en las primeras dos semanas de un proyecto. El costo de una mala arquitectura se paga durante años: en retrasos, en bugs recurrentes, en funcionalidades que tardan el triple de lo esperado, y eventualmente en la reescritura completa del sistema.

En Ab4cus, la arquitectura no es un entregable separado que se cobra aparte. Es la forma en que construimos todo — desde el primer día, en cada proyecto, sin importar el tamaño. Porque sabemos que el sistema que construimos hoy es el sistema que el cliente va a querer crecer mañana.

Si quiere entender cómo se vería la arquitectura correcta para su proyecto específico, empiece por calcular el alcance:

→ Ver la estimación de mi proyecto en minutos