Your monolith served you well. It got you to market, it proved the business model, and it handled your first thousand users. Now it's struggling with your ten-thousandth — and the team is spending more time fighting the codebase than shipping features. Sound familiar?
Signs Your Monolith Is the Bottleneck
Deployment fear. Every release is a full deploy of everything, and the blast radius of any bug is the entire application. Deployments that should be routine become coordinated events with rollback plans.
Scaling is all-or-nothing. Your search feature needs 10x more CPU than your checkout flow, but you can't scale them independently. You're paying for 10x compute across the entire application.
Team coupling. Three teams working on three features constantly create merge conflicts and break each other's code. The codebase has become a coordination bottleneck.
The Pragmatic Middle Ground
The microservices movement overcorrected. Going from one monolith to fifty services creates a distributed systems nightmare that most teams aren't equipped to handle. The answer is usually somewhere in between: 3-7 well-defined services, split along natural domain boundaries.
I call this "right-sized services" — not micro, not mono, but appropriately scoped for your team and traffic patterns.
The Migration Playbook
- Identify the pain point. Don't split everything — split the thing that hurts. Is it the search system that needs independent scaling? The payment processing that needs isolated deployment? Start there.
- Define the boundary. The service boundary should follow a domain boundary. If extracting a service requires passing 15 different data types back and forth, the boundary is wrong.
- Build the service alongside the monolith. The new service runs in parallel. A feature flag routes traffic to the new service for a percentage of requests. Validate correctness before increasing traffic.
- Migrate the data. This is the hardest part. The new service needs its own data store, which means migrating data and ensuring consistency during the transition. I use event-driven synchronization during migration, then cut over when the new service is authoritative.
- Decommission the monolith module. Once the service is stable and handling 100% of traffic, remove the corresponding code from the monolith. Don't leave dead code behind.
What You Need Before Starting
CI/CD for each service. If you can't deploy services independently, you haven't gained anything. Set up independent pipelines before extracting services.
Observability across services. Distributed tracing, centralized logging, and service-level dashboards. When something breaks, you need to know which service, which request, and which dependency.
An API contract. The interface between services is a contract. Define it upfront with OpenAPI or Protocol Buffers, version it, and test it. Loose contracts between services create the same coupling you were trying to escape.
When to Stay Monolithic
If your team is under 5 engineers, your traffic fits on a single server, and your deployment pipeline works — stay monolithic. A well-structured monolith with clear module boundaries outperforms a poorly designed distributed system every time. Extract services when you have a concrete problem, not a theoretical one.