Modular core banking: why well-designed monoliths beat premature microservices

Every core banking project eventually faces the same question: microservices from day one, or a modular monolith that evolves into services as real needs emerge?

The most common mistake

Decomposing by technical layer (a "database" service, a "rules" service, an "API" service) instead of by business domain. The symptom is always the same: closing an account requires orchestrating synchronous calls across five different services, and a failure in any one of them takes down the entire operation.

Bounded contexts that hold up in practice

In mature core banking platforms, the boundaries that stay stable over time are:

• Accounts & Ledger — the accounting source of truth, isolated and auditable.
• Payment Methods — PIX, boletos, wire transfers, cards: each with its own lifecycle, but sharing the same ledger.
• Credit — decision engine and contract management, with a strong need for rule versioning.
• Compliance — KYC, AML and regulatory reporting, which needs to observe every domain without coupling to them.

The modular monolith as a starting point

Starting with a modular monolith — modules with clearly defined code boundaries, communicating through clear internal contracts — makes it possible to evolve toward independent services exactly where scale or team structure demand it, without paying the cost of network calls and eventual consistency where they bring no benefit.

Decomposing into microservices stops being dogma and becomes an engineering decision, made with load data and team organization in mind — not fashion.