We Split the Monolith and Made Everything Worse
A team extracted a billing service from a monolith to improve deploy velocity. Deploys got faster. Everything else got slower, harder to debug, and more fragile. The architecture was right. The boundary was wrong.
- Deploy pipeline for the monolith was 45 minutes and blocking feature velocity
- Billing logic was the most frequently changed module
- Three teams were stepping on each other in the same codebase
Slow deploys were a real problem — engineers were batching changes to avoid waiting, which increased risk per deploy and made rollbacks harder. The pressure to extract something was legitimate. The question was what to extract, and whether the extraction boundary matched the actual coupling in the system.
The Scenario
You're an engineering manager at a fintech startup. Your monolith's deploy pipeline takes 45 minutes. Three teams are blocked on each other. The billing module is the most frequently changed code. Your VP of Engineering is asking for a plan. What do you propose?
No hints. Just judgment.
Optimizing the deploy pipeline is genuinely useful and low-risk. But it addresses the symptom (slow deploys) without addressing the cause (teams coupled through shared code ownership). After the pipeline is faster, the coordination overhead remains: merge conflicts, shared file ownership, and cross-team dependencies still slow everyone down. Pipeline optimization is a good first step, not a complete solution.
- Frequency of change correlates with pain, not with independence
- Shared database access is the strongest coupling — stronger than API calls or code imports
- A microservice with 14 cross-service data dependencies is a distributed monolith
- Measure coupling before you cut — the right boundary is rarely the obvious one
- Reverting an architectural mistake early is cheaper than maintaining a bad abstraction
- Billing extraction reverted — eliminated the distributed monolith pattern
- Notification service extracted cleanly with zero production incidents
- One team fully unblocked for independent deployment
- Internal modularization established clear boundaries for future extractions
Related
A Database Migration Took Down the Entire Platform
A routine schema migration brought down a multi-tenant SaaS platform for 47 minutes during business hours. The migration itself was correct. The deployment strategy was the failure.
Read more ArchitectureThe Cloud Migration That Almost Broke Our Export Service
We had three weeks to migrate file storage from AWS S3 to Azure before our AWS contract renewed. The codebase had a clean storage abstraction built for exactly this scenario. We almost shipped without checking whether everything actually used it.
Read more