Architecture

Modular monolith versus microservices in banking architecture

The choice between modular monolith and microservices in a bank is not a question of technology fashion but of team operational maturity, core state, and actual business flow. This article walks through when each approach is justified, which architectural mistakes are typical for Central Asian banks, and how to avoid system fragmentation without business cause.

Discuss Your Challenge

This architectural article walks through the choice between modular monolith and microservices in a banking system from the perspective of operational maturity, core state, and actual business tasks.

What architecture challenge is being solved

Most regional banks face an architectural choice: modernize the existing core banking monolith with its integration layers or break it into microservices. The decision is most often made under the influence of vendor marketing and conference presentations, not from analysis of actual operating flow, team maturity, and business tasks. The result is dozens of new microservices serviced by a team unprepared to operate them, or further accumulation of functionality in a monolith that becomes a bottleneck for any change.

Which systems, data flows and teams are involved

Core banking system (ABS) — Colvir, CFT, OpenWay, SAP Banking — usually a large monolith
Integration layer — ESB, API gateway, event bus
Product systems — digital banking, mobile app, credit pipeline, anti-fraud, AML
Development teams — size, DevOps experience, readiness for microservices operating model
Infrastructure — capacity, observability, security, SLA

Typical architecture mistakes

Breaking the system into microservices by technical criteria (one service = one table), not by business domain
Starting microservices before the team can operate them in production — no observability, CI/CD, on-call
Trying to simultaneously replace the monolithic core with microservices — a 36+ month project with high failure probability
Keeping the monolithic core surrounded by dozens of point integrations without a layer — every change touches 5+ systems
Declaring 'we have microservices' while actually running a distributed monolith with synchronous service dependencies
Microservices for a 5-developer team — operational load exceeds benefits

Possible approaches

Keep the monolithic core, build an integration layer around it (event bus + API gateway), new products as separate modules or services. The path of most regional banks.
Modular monolith — a single system with clear module boundaries and explicit interfaces. Suits 10-30 developer teams.
Microservices by business domains (credit, deposit, cards, AML) — justified for a large bank with 50+ developer team and mature DevOps
Hybrid — monolithic core, microservices product and channel layer around it. An intermediate path for most.

How to avoid unnecessary core replacement

Core replacement is a separate strategic decision, not a precondition for modernization. Modern core systems support business pace given an integration layer around them. The strangler pattern strategy — gradually move functionality from the core into new modules or services as it ages, without replacing everything at once. This reduces program risk by orders of magnitude and delivers measurable effect at each phase.

Risks, dependencies, constraints

Team readiness for microservices is the main risk. Without mature DevOps, microservices become a burden
Dependency on observability — without full monitoring/tracing, microservices architecture is unmanageable
Microservices operational expenses are higher — more infrastructure, more teams, more coordination
Distributed system security is harder — each service needs its own access controls
Regulatory requirements (AML, reporting) are simpler in a monolith — centralized control needed

How a phased roadmap should look

Months 1-3: diagnose current architecture, assess team maturity, formulate target model
Months 4-9: build integration layer (event bus, API gateway), unified customer profile, observability
Months 10-15: pilot product block (usually digital banking or new credit product) on the new architecture
Months 16-24: expand across product blocks, gradually move functions out of the core
Core replacement decision — after 24-36 months, when it is clear what specifically became the bottleneck

→

What else is worth exploring

Topics from the same area we usually explore together

Solution

These are not just articles

I do not just write about this. I can come in, examine your situation and design a solution for your specific landscape.

Discuss applying this →

← Back

Ready to discuss your challenge?

Tell me what's not working or what needs to be built. First conversation — no obligations.

Discuss Your Challenge Write on Telegram

Usually respond within a few hours