Reversing a Microservices Migration That Was Making Things Worse, Not Better
The Situation
A fintech startup had spent 14 months migrating from a Django monolith to 23 microservices. Deployment: 12 min → 4 hours. Incidents tripled. 40% of engineering time went to inter-service issues instead of product.
The Problem
The migration was driven by technical idealism, not an actual scaling problem. With 12,000 users, microservices offered zero benefit while adding enormous complexity that nobody fully understood.
What We Did
Made the case with data first: deployment frequency -60%, MTTR +300%, product feature time -30%. This framed it as a business decision, not a technical debate. "Strategic consolidation, not full rollback": identified which services had genuine reasons to be separate. 21 of 23 services consolidated back into a well-structured Django monolith over 8 weeks. Fraud detection and notifications remained separate with documented justification. Used feature flags throughout.
The Result
Deployment: 4 hours → 18 minutes. Incident rate: pre-migration baseline. Feature time: 60% → 87%. More shipped in 3 months post-consolidation than in the previous 9.
Architectural complexity is a cost, not just a tradeoff — and the cost compounds every day until you pay it down.