Decomposing a monolith for scaled agile teams

What's really being asked

This question assesses your senior-level experience with large-scale architectural transitions. It's not about knowing the definition of a microservice; it's about your practical understanding of the three hardest problems in decomposition: data, interfaces, and shared dependencies. The interviewer wants to see a phased, pragmatic approach that acknowledges the organizational shift (scaled agile) and its coupling to the technical architecture. They are testing your grasp of domain-driven design, API lifecycle management, and distributed data patterns.

The full answer

A strong answer outlines a strategy in three parts, mirroring the question. First, for team alignment and decomposition, you would start by identifying business capabilities and mapping them to bounded contexts, which will define the new service boundaries. Second, for API contracts, you would propose using a schema-first approach (like OpenAPI) to define clear, versioned interfaces and an API Gateway as the single entry point to abstract the backend changes from clients. Third, for data consistency, you would explain that each microservice must own its own data. To handle transactions that span services, you would propose asynchronous, event-driven patterns or sagas, using message-oriented middleware like Kafka or Azure Service Bus. For shared libraries, you would advocate for minimizing them, preferring code duplication over tight coupling, and establishing a clear governance model for any truly necessary shared code.

The mistakes people make

A major red flag is proposing a shared database between microservices. This creates a 'distributed monolith' and defeats the purpose of independent deployment and team autonomy. Another common mistake is suggesting a 'big bang' rewrite instead of an incremental, strangler-fig pattern. Candidates also stumble by focusing too much on specific technologies (e.g., 'I'd use Kubernetes and Go') without explaining the 'why' behind the architectural principles. Finally, hand-waving away the data consistency problem ('we'll just use two-phase commit') shows a lack of experience with the complexities of distributed systems.

What usually comes next

Expect questions like: 'How would you handle a situation where two teams disagree on the boundary of a bounded context?', 'Walk me through the first three steps you'd take in the first month.', 'How do you prevent the API gateway from becoming a new monolith?', 'Describe how you would manage versioning for a breaking API change affecting multiple consumer teams.'

A concrete example

To extract the first service, I'd choose a low-risk, high-value business capability, like 'User Profile Management.' First, I'd define its bounded context and the data it owns. Then, I'd create a new service with its own database, replicating only the necessary user data. I'd define a v1 API for this service using OpenAPI. I would then deploy an API Gateway and use the Strangler Fig pattern: route all '/api/users/profile' calls to the new service, while all other traffic continues to the monolith. The monolith would be updated to call the new service's API for profile data, removing its own internal logic for that function. This allows for an incremental rollout with clear rollback paths.