Decomposing a Monolith: Technical Strategy

What's really being asked

This question probes your senior-level ability to plan a complex, multi-quarter migration. The interviewer is looking for pragmatism, risk management, and an understanding that organizational structure (multiple teams) is deeply linked to technical architecture. They want to see if you can manage the messy middle of the transition, not just the ideal end state.

The full answer

First, a decomposition strategy based on business capabilities, using Domain-Driven Design (DDD) and Bounded Contexts to define service boundaries. Propose an incremental approach like the Strangler Fig pattern. Second, a data consistency plan where each new service owns its data. Use an event-driven architecture (e.g., with Kafka or Azure Service Bus) for cross-service consistency, avoiding distributed transactions. Third, an API contract strategy using an API Gateway as the single entry point, routing requests to either the new service or the legacy monolith. This provides a stable interface for clients. Fourth, a cautious approach to shared libraries. Minimize them to maintain service independence. If a library contains business logic, it's a sign of a poor boundary.

The mistakes people make

Proposing a "big bang" rewrite. This approach is infamous for its high failure rate, often exceeding 70%, and freezes feature development for 12-24 months. Another major red flag is creating a "distributed monolith" by having services make synchronous calls to each other's databases or by putting core business logic in a shared library, which defeats the purpose of independent deployment. Finally, completely ignoring the data migration strategy is a common omission. A plan must exist for moving data from the monolith's database to the new service's database, often involving dual-writes or complex synchronization jobs during the transition.

What usually comes next

How would you handle a transaction that needs to span two services? (The correct answer involves the Saga pattern, not two-phase commit). How do you ensure observability in this new distributed system? (Talk about the three pillars: centralized logging, distributed tracing, and metrics). What's the first service you would extract, and why? (Look for a service with few dependencies and high business value).

A concrete example

For an e-commerce monolith, a good first service to extract is "Product Reviews." It has few write dependencies. Create a new review-service with its own database. An API Gateway routes /api/reviews/* to the new service. When a new product is added in the monolith, it publishes a ProductCreated event. The review-service subscribes to this to know which products exist, maintaining its own local data without directly querying the monolith's product database.