We just crossed 100 employees and $20M ARR at our financial services platform. The monolithic Rails application that got us here is now our biggest bottleneck. Build times hit 35 minutes. Three teams constantly merge-conflict over shared code. Our database queries are slowing to a crawl. Every “quick fix” takes a week.
Sound familiar?
My engineering leadership team is debating three paths forward, and I’m curious what this community thinks:
Option 1: The Big Bang Rewrite
Some of our senior engineers want to rewrite the entire system as microservices from scratch. They argue we know the domain now, we can build it right this time, and the monolith’s technical debt is too deep to refactor.
I’m skeptical. I’ve seen too many “six-month rewrites” turn into 18-month death marches while competitors ship features. The data backs up my concern—most Big Bang rewrites fail or deliver drastically reduced scope.
Option 2: Refactor to Modular Monolith
Our architect suggests keeping a single deployable but enforcing strict module boundaries. Think bounded contexts with clear APIs, separate databases per module, but one deployment unit. Faster to ship, keeps operational complexity manageable, preserves team velocity.
The appeal: we get architectural discipline without operational overhead. The downside: we’re still deploying everything together, which means blast radius stays large.
Option 3: Strangler Fig Pattern
Extract services incrementally using the strangler pattern. Start with our payment processing (PCI compliance isolation makes sense), then gradually migrate high-load endpoints. Run monolith and services side-by-side for 12-18 months.
Lower risk, but also slower transformation. And let’s be honest—we might end up with the worst of both worlds: a distributed monolith.
The 2026 Context That Changes Everything
Here’s what’s making this decision harder: 42% of organizations are consolidating from microservices back to modular monoliths in 2026. The operational overhead of distributed systems is overwhelming teams that don’t have Google-scale problems.
The cost data is eye-opening. Microservices infrastructure runs 3.75x to 6x more expensive than monoliths—we’re looking at $40k-65k per month versus $15k for equivalent functionality. That’s real money when you’re pre-Series B.
What I’m Really Asking
The technical decision framework is clear enough. What I’m struggling with is distinguishing between:
- Actual scaling problems we have today (slow builds, database bottlenecks, team conflicts)
- Future problems we think we’ll have (Netflix-scale traffic, hundreds of engineers, global latency requirements)
Most startups over-architect for problems they’ll never face. But some hit exponential growth and wish they’d invested in scalability earlier.
For those who’ve been through this inflection point:
- What signals told you it was time to move beyond the monolith?
- Did you choose evolutionary architecture or revolutionary change?
- What would you do differently knowing what you know now?
- How did you balance engineering investment versus feature delivery?
At my previous role at Adobe, we had the luxury of dedicated platform teams. Here, every hour spent on architecture is an hour not shipping customer value. But technical debt compounds, and I’ve seen too many startups choke on their own success.
What would you do?
Related context: Our team is 40+ engineers across 3 squads, we’re processing ~500k transactions/day, database is 2TB and growing 30% quarterly, deploy frequency dropped from 3x/day to 1x/day due to fear and coordination overhead.