India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Microservices Modernization: Decomposing Monoliths by Business Domain
Microservices modernization is a planned re-architecture that splits a monolithic application into independently deployable services, each owning one business capability and its data. NTSPL runs these programmes one seam at a time using domain-driven design, strangler routing, per-service databases and event-based consistency, for product companies and enterprises whose monolith now limits release speed or scale.
Delivered on
In scope
When the monolith, not the infrastructure, is the bottleneck
A monolith becomes the problem when 40 developers queue behind one release train, a horoscope-matching bug takes down checkout, and scaling the busiest screen means scaling everything. The usual fix, cutting the code into services, often produces a distributed monolith: 25 services sharing one database, calling each other six deep, and still deploying together. Latency rises, incidents get harder to trace, and the team now pays for a container platform on top of the old coupling. The hard part of microservices is the data split and the transaction boundaries, not the code.
NTSPL decomposes by business capability using event storming with domain experts, then extracts one bounded context at a time behind a strangler router, so the monolith keeps serving everything not yet moved. Each new service owns its schema from day one; change data capture backfills it and a transactional outbox publishes its events. Cross-module joins become read models, and multi-step flows become sagas with explicit compensations. We stop extracting when the remaining monolith is stable and rarely changed, not when everything is a service.
Signs an application needs decomposition rather than more servers
Signals you need Microservices Modernization
- More than 25-30 engineers commit to one codebase and release trains slip on merge and regression conflicts.
- One capability (search, pricing, inventory) needs 5-10x the capacity of the rest at peak, forcing you to scale the whole application.
- A defect in a low-value feature has taken down revenue paths at least twice in a year.
- Lead time from commit to production exceeds two weeks even for small changes.
- Different capabilities need different data stores, such as a search index, a ledger or a document store, but are forced into one RDBMS.
When to choose something else
- Teams under about 15 engineers on one product: a modular monolith with enforced boundaries gives most of the benefit at a fraction of the operating cost.
- If the goal is getting to cloud quickly, replatform first under Cloud Migration & Modernization and decompose later when release speed becomes the constraint.
- No automated tests on critical paths and no CI pipeline: fix delivery engineering (DevSecOps & CI CD) first, because every extraction depends on fast regression feedback.
What a decomposition programme delivers
Domain discovery
Event storming with product and operations to map bounded contexts, aggregates, domain events and a context map.
Strangler routing
Gateway or ingress rules that send migrated routes to new services and the rest to the monolith, with per-route rollback.
Data ownership split
Per-service schemas, CDC backfill, dual-read verification and removal of cross-context joins and foreign keys.
Event backbone
Transactional outbox, broker topics, schema registry and idempotent consumers.
Saga and workflow design
Orchestrated or choreographed sagas with compensations for booking, payment and refund flows.
Service template
Golden-path repository with health checks, tracing, config, secrets and pipeline, so every service starts production-ready.
Strangler routing, per-service data and an event backbone
Strangler-Routed Decomposition with Outbox Events
An edge router splits traffic between the monolith and newly extracted services, route by route. Each service owns its database and publishes domain events through an outbox to a broker, from which other services and the residual monolith build their read models.
Select any component
Strangler-Routed Decomposition with Outbox Events: click any of its 11 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Running decomposed services on each cloud
MSK carries high-volume ordered events, EventBridge lower-volume domain events, and Step Functions orchestrates sagas. ECS service-to-service traffic uses Service Connect, since AWS App Mesh was discontinued on 30 September 2026.
Container Apps with built-in Dapr suits teams new to microservices: pub/sub, state and service invocation without running a mesh. Debezium can publish to Event Hubs' Kafka endpoint without a self-managed cluster.
Datastream feeds CDC from the monolith's database, Pub/Sub carries events with ordering keys, and Workflows orchestrates sagas. Cloud Run is our default for extracted services until a context needs GKE.
Decomposition choices that decide success
Where to draw service boundaries
Draw boundaries around business capabilities whose data changes together, confirmed by co-change analysis: modules changed in the same commit more than 30% of the time belong in one service. Size services so a team of 5-8 can own them. If a service needs two teams, split it; if two services always deploy together, merge them back.
Synchronous calls or events
Limit synchronous chains to two hops on any user request. Data a service needs repeatedly from another context, such as prices, profiles or availability, should arrive by event into a local read model. Keep synchronous calls for commands that must succeed now, like payment authorisation, with timeouts under one second and circuit breakers on every call.
Orchestration or choreography
Use an orchestrator (Step Functions, Durable Functions, Workflows or Temporal) when a flow has more than four steps, needs compensations, or carries an SLA someone must report on. Choreography suits two or three loosely related reactions, such as sending notifications after a booking. Mixed flows are fine; undocumented flows that nobody can draw are not.
Sequencing the database split
Never move code and data in one step. First extract code that reads shared tables through a dedicated interface; then create the service schema and backfill it with CDC; run dual reads for 2-4 weeks comparing results; only then switch writes and drop the old tables. Each step has its own rollback and its own go/no-go check.
Extracting bounded contexts one at a time
Event storming and context map
Workshops with domain experts produce bounded contexts, a context map and an extraction order.
Service template and event backbone
Build the golden-path template, broker, schema registry and tracing used by every service.
First extraction with dual reads
Extract the highest-scoring context behind the router, backfill with CDC and compare reads.
Write cutover and stabilisation
Switch writes, retire old tables and code paths, and measure lead time and incidents.
Next contexts
Extract one or two contexts per quarter, re-scoring the remaining modules each time.
What you receive
Measuring whether decomposition is working
| KPI | Typical target |
|---|---|
| Lead time for changes in extracted services | Under 1 day |
| Services released without a coordinated deployment | 100% |
| Synchronous hops on critical user requests | 2 or fewer |
| Change failure rate | Under 10% |
| Monthly code changes still landing in the monolith | Falling quarter on quarter |
How microservices programmes turn into distributed monoliths
| Risk | How NTSPL prevents it |
|---|---|
| Shared database kept temporarily, then permanently | Write access to another context's tables is revoked at database-role level from the first extraction; exceptions carry an expiry date. |
| Lost or duplicated events | Outbox publishing, idempotency keys on consumers and daily count reconciliation between service and monolith during migration. |
| Latency growth from chatty services | Hop limits checked in design review and visible in traces; read models replace repeated lookups. |
| Operational load outpacing team skills | Service count grows only as fast as on-call capability; NTSPL engineers pair with each owning team for its first two extractions. |
Microservices or a modular monolith: which should we choose?
Choose a modular monolith if one team of under 15-20 engineers owns the product, load is uniform and weekly releases are acceptable. Enforce module boundaries with tooling such as ArchUnit, Deptrac or NDepend rules and keep one deployable. Choose microservices when several teams must release independently, parts of the system scale very differently, or capabilities need different data stores. The decision is organisational as much as technical, because services should map to teams. A practical middle path is to modularise first, then extract only the two or three modules that genuinely need independent scale or release.
Key facts: Microservices Modernization
Microservices Modernization in Practice
2 Microservices Modernization scenarios, from Online matrimony and Online bus ticketing, plus related platform case studies.
Matrimony platform extracts match search and serves 4x peak queries at 420 ms
Bus ticketing platform ends festive double-booking by extracting seat inventory
Logistics SaaS scales shipment tracking to 9 crore events a day on EKS with Karpenter
Health TPA meets 1-hour cashless pre-auth target with AKS and KEDA-scaled adjudication
Microservices Modernization: Frequently Asked Questions
How long does a monolith decomposition take and what does it cost?
Expect 10-12 weeks for the first bounded context, including the template and event backbone, then 6-8 weeks per later context. A 500,000-line monolith usually reaches a stable state, with core contexts extracted and the residue rarely changed, in 12-18 months. Services cost runs roughly INR 18-30 lakh per context after the first.
Do we need Kubernetes for microservices?
No. Up to about 15-20 services, Cloud Run, Azure Container Apps or ECS on Fargate give independent deployment and scaling with far less platform work. Kubernetes becomes worthwhile when you need custom scheduling, mesh features or consistent operation across clouds.
How do you handle transactions that span services?
We replace distributed transactions with sagas. Each step commits locally and publishes an event; a failure triggers compensating actions, such as releasing a seat or reversing a payment hold. A transactional outbox guarantees the event is published whenever the local commit succeeds, so no step is silently skipped.
Will the monolith keep working during the migration?
Yes. The strangler router sends only migrated routes to new services; everything else reaches the monolith unchanged, and each route can be switched back in seconds if metrics degrade. Users should notice nothing beyond faster pages on the migrated paths and fewer outages spreading between features.
How does decomposition affect DPDP Act 2023 compliance?
It usually helps. Concentrating personal data in one owning service, such as profile or customer, lets you apply consent checks, erasure requests and access logging in one place rather than across a shared schema. We map every event that carries personal data and pass only identifiers elsewhere.
Can AI coding tools decompose the monolith for us?
They help with analysis and code movement, not boundary decisions. We use assistants to generate adapters, tests and boilerplate, which shortens each extraction, but bounded contexts come from domain workshops and data-coupling analysis that tools cannot do alone. Every generated change still passes the same contract tests.