Splitting a Core Banking Monolith into Microservices for a Digital Bank

services extracted in 12 months

Qtr→daily

deployment frequency

~70%

smaller incident blast radius

downtime during the migration

The Client

A digital bank serving several hundred thousand retail and small-business customers with accounts, cards, payments, and lending. The bank had grown fast on a core platform originally built fifteen years earlier — a single .NET application that handled everything from ledger postings to statement generation.

The Challenge

The monolith worked — money moved, balances were right — but the organization around it had outgrown it. Every change, however small, shipped in one release train with everything else, so the bank had settled into quarterly deployments preceded by weeks of regression testing and a change-freeze. Product teams queued for months to ship features; competitors shipped weekly.

Reliability was the sharper problem: because everything ran in one process against one database, a defect in statement generation could degrade payment processing. Regulators and the board were asking pointed questions about operational resilience. A rewrite was off the table — nobody rewrites a live core banking ledger — so the bank needed a partner who could decompose the system incrementally, with the ledger's correctness guarantees intact and no customer-visible downtime.

What We Did

Dillo scoped the modernization as an outsourcing engagement: an architect and eight senior engineers working in two streams, alongside the bank's own platform team. We followed the strangler-fig pattern — extract, run in parallel, verify, cut over — one domain at a time. We wrote about the approach here.

Ran a domain-mapping phase with the bank's engineers to find real seams — payments, cards, customer onboarding, statements, notifications, lending — and sequenced extraction by risk and value, leaving the ledger core for last.
Introduced Kafka as the event backbone, publishing domain events from the monolith first so new services could be built against real production event streams before any cutover.
Extracted services as containerized C#/.NET applications on Kubernetes, each with its own PostgreSQL database, replacing shared-table coupling with explicit contracts.
Used parallel-run verification for every extraction: the new service processed shadow traffic and its outputs were reconciled against the monolith's until they matched over a full statement cycle.
Executed zero-downtime cutovers with routing at an API gateway and instant rollback paths — no maintenance windows, no customer impact, through twelve months of migrations.
Built the CI/CD and observability foundation — per-service pipelines on Azure, distributed tracing, and SLO dashboards — so the bank's teams could own their services independently.

The Results

14 services extracted in 12 months, covering the majority of change-heavy domains; the remaining core is smaller, calmer, and better understood.
Deployment frequency went from quarterly release trains to daily deploys for extracted domains, each shippable independently.
Incident blast radius shrank by roughly 70% — a failure in one domain no longer degrades the rest of the bank.
Zero downtime across every cutover, with ledger reconciliation clean throughout.
Product teams now own services end to end, and the bank's resilience posture answered the questions its regulators were asking.

Figures reflect outcomes reported for this engagement; they are project results, not audited benchmarks.