Core banking modular: por qué un monolito bien diseñado gana a los microservicios prematuros

Todo proyecto de core bancario termina enfrentando la misma pregunta: ¿microservicios desde el primer día, o un monolito modular que evoluciona hacia servicios conforme aparece la necesidad real?

El error más común

Descomponer por capa técnica (un servicio de "base de datos", otro de "reglas", otro de "API") en lugar de por dominio de negocio. El síntoma es siempre el mismo: para cerrar una cuenta hay que orquestar llamadas síncronas entre cinco servicios distintos, y un fallo en cualquiera de ellos derriba toda la operación.

Límites de contexto que funcionan en la práctica

En plataformas de core bancario maduras, los límites que se mantienen estables en el tiempo son:

• Cuentas y Ledger — la fuente de verdad contable, aislada y auditable.
• Medios de pago — PIX, boletos, transferencias, tarjetas: cada uno con su propio ciclo de vida, pero compartiendo el mismo ledger.
• Crédito — motor de decisión y gestión de contratos, con una fuerte necesidad de versionado de reglas.
• Compliance — KYC, AML y reporte regulatorio, que necesita observar todos los dominios sin acoplarse a ellos.

El monolito modular como punto de partida

Empezar con un monolito modular — módulos con límites de código bien definidos, comunicándose mediante contratos internos claros — permite evolucionar hacia servicios independientes justo en los puntos donde la escala o la organización de los equipos lo exigen, sin pagar el costo de red y consistencia eventual donde no aporta beneficio.

La descomposición en microservicios deja de ser un dogma y pasa a ser una decisión de ingeniería, tomada con datos de carga y organización de equipos — no por moda.