We're scaling to 2M users on a monolith—when does the pressure to migrate become real?

General
1

We’re scaling to 2M users on a monolith—and the board keeps asking when we’re moving to microservices. I lead engineering at a financial services company, and we’ve grown from 200K to 2M users in 18 months—all on a monolithic Rails application.

The Situation

Our platform handles stock trading, portfolio management, and financial analytics. We’re processing ~50K transactions daily during market hours. The monolith is showing strain:

  • Database queries slow down during peak trading (9:30-10:30am ET)
  • Deployments make everyone nervous (we do them at 8pm when markets are closed)
  • The codebase is 300K+ lines, and new engineers take 3-4 weeks to understand the domain boundaries

Last board meeting, one of our investors (ex-Netflix engineer) asked: “When are you modernizing to microservices?” The CTO is fielding pressure. I’m feeling it too.

But Here’s What Makes Me Pause

I was just reading about Amazon Prime Video moving BACK to a monolith and reducing infrastructure costs by 90%. Segment did something similar. These aren’t small companies—they tried microservices at scale and reversed course.

Meanwhile, our real challenges are:

  • We need better database indexing and query optimization
  • Our deployment process needs CI/CD improvements regardless of architecture
  • The team needs clearer module boundaries (which we could do IN the monolith)

The Tension I’m Feeling

Option A: Bite the bullet, spend 12-18 months migrating to microservices. Modern architecture, independent team ownership, cool engineering problems. But we’d essentially pause feature development.

Option B: Stay monolithic, invest in making it better—modular structure, better tooling, database optimization. Ship features. Risk being “behind” architecturally.

There’s this industry narrative that monoliths are “legacy” and microservices are “modern.” But the data shows that microservices benefits only appear with teams over 10-15 developers working on a service. We have 40 engineers total across the entire platform.

What I Need From This Community

I want to hear from folks who’ve actually lived through this decision:

  1. What were your actual triggers for migrating (not theoretical, but real pain points that forced your hand)?
  2. If you stayed monolithic, how did you make it work at scale?
  3. If you migrated to microservices, was it worth it? What would you do differently?
  4. How do you push back on architectural pressure when you’re not convinced it’s the right move?

I’m not looking for textbook answers—I’ve read those. I want to know what actually happened when you made this choice, and whether you’d do it again.

Anyone been in this spot? What did you learn?

2

Luis, I’ve been exactly where you are. At my previous company (mid-stage SaaS, ~150 engineers), we faced this same pressure around the 5M user mark. Here’s what I learned.

The Migration Decision Framework We Used

We built a simple framework to evaluate this, and it saved us from making an expensive mistake. Migration to microservices is justified when all three of these conditions are true:

  1. Organizational scale: 50+ engineers with clear team boundaries
  2. Domain clarity: Distinct business domains that truly don’t need to talk constantly
  3. Independence requirement: Different parts of the system need radically different deployment cadences or scaling characteristics

Your situation: 40 engineers, one platform. You’re not there yet.

What We Actually Did: The Modular Monolith Route

Instead of microservices, we went with a modular monolith—essentially carving clear boundaries inside the existing system without the operational overhead of distributed services. Results after 12 months:

  • Deployment anxiety dropped (we separated the build/test pipeline by module)
  • New engineer onboarding went from 6 weeks to 2 weeks (clearer boundaries)
  • Database challenges were solved by proper indexing and read replicas—not architecture changes
  • We shipped 40% more features than the previous year

The research backs this up: microservices benefits only appear with teams of 10-15+ developers per service. Smaller teams see net productivity losses from coordination overhead.

Your Real Problems Aren’t Architecture

Look at your list again:

  • Database slowdowns → indexing, query optimization, caching, read replicas
  • Deployment anxiety → CI/CD improvements, better testing, feature flags
  • Domain confusion → module boundaries, documentation, architectural guidelines

None of these require microservices. All of them will need solving even if you migrate.

The Question You Should Ask Your Board

Next time the microservices question comes up, ask: “What specific business outcome would this unlock?”

If the answer is “we’ll scale better” → Show them Amazon Prime Video’s 90% cost increase with microservices
If the answer is “we’ll ship faster” → Show them the data on coordination overhead
If the answer is “it’s more modern” → Ask what “modern” means for customers who just want fast, reliable features

When You SHOULD Migrate

I’m not anti-microservices. We eventually extracted two services from our monolith:

  1. Background job processing (totally different scaling needs, Python vs our Ruby app)
  2. Real-time notifications (WebSocket service that needed independent deployment)

We did this when the pain was undeniable and the boundaries were crystal clear. Not before.

Your fintech platform will likely need this eventually—maybe the trading engine needs to scale independently, or compliance reporting needs total isolation. But you’ll know when that day comes. The pressure will come from engineering constraints, not board questions.

Bottom line: You’re at 40 engineers and 2M users. Focus on making your monolith excellent, not modern. The ROI is 10x better.

3

Oh man, this hits close to home. I’m going to share something I don’t talk about much, but I think it’s relevant here.

The Startup That Died During “Modernization”

My co-founder and I built a B2B scheduling platform back in 2023. We had about 800 customers, $40K MRR, a monolithic Django app, and a team of 5 engineers. Things were actually working.

Then we hired a senior engineer from Uber. Great guy. First architecture review, he said: “This won’t scale. We need microservices.”

We trusted him. He had Uber on his resume. We had…nothing remotely close to that scale.

What Happened Next

We spent 6 months breaking apart the monolith:

  • Split into 8 microservices (why 8? because it felt “right”?)
  • Rebuilt our deployment pipeline
  • Set up service mesh, API gateway, the whole deal
  • Convinced ourselves we were “real engineers” now

During those 6 months:

  • Zero new features shipped
  • Customer requests piled up in a spreadsheet
  • Our main competitor launched 3 major features we’d been planning
  • Support tickets increased (performance got worse, not better)
  • 2 engineers quit because they wanted to “build things that matter”

We burned through our runway chasing architectural purity while our competitor shipped features. They’re still around. We shut down in early 2025.

The Lesson That Cost Me Everything

Architecture should serve users, not engineering egos (including mine).

Our “scaling problems” were actually:

  • A few slow queries → could’ve been fixed with indexes
  • Occasional deployment failures → could’ve been fixed with better testing
  • Code complexity → could’ve been fixed with better boundaries inside the monolith

We solved theoretical future problems while ignoring real current ones.

What I’d Tell 2023 Me

“You have 800 customers. Your competitor has 2,000. The race isn’t about who has the coolest architecture—it’s about who solves customer problems faster.”

The industry is literally moving back to monoliths after learning this the hard way. Companies like Amazon, Segment, and others tried microservices and reversed course because the complexity wasn’t worth it.

For Luis

You have 2M users. We had 800 customers. If we couldn’t justify microservices, I’m not sure you can either.

That investor asking about “modernization”? Ask them: “What customer problem does this solve?” If the answer is about engineering elegance and not customer value, that’s a red flag.

Michelle’s framework above is gold. If you don’t have 50+ engineers and truly independent domains, you’re cosplaying Netflix without Netflix’s resources or problems.

Ship features. Make customers happy. When architecture becomes a real constraint (not a theoretical one), you’ll know because you’ll be in actual pain. Not board-meeting pressure. Real, “we can’t deploy without taking the site down” pain.

Save your company from the mistake that killed mine.

4

Luis, Michelle and Maya covered the technical and product angles brilliantly. I want to add the organizational dimension that often gets overlooked in these architecture debates.

The People Problem Nobody Talks About

I led a team through a failed microservices migration at a previous company. We had all the right technical conditions—100+ engineers, clear domains, solid DevOps culture. Or so we thought.

What actually happened:

  • Teams that used to ship weekly suddenly needed 2-3 weeks for cross-service changes
  • Our standup turned into service dependency negotiation sessions
  • Engineers optimized for their service metrics, not product outcomes
  • Junior engineers got lost in the distributed complexity
  • Debugging production issues went from “check the logs” to “trace across 12 services”

We spent 18 months on the migration. Feature velocity dropped 30%. We eventually had to consolidate back—and we were in the 42% of organizations that went back to modular monoliths according to the CNCF survey.

The Organizational Readiness Test

Before considering microservices, ask yourself:

1. Do you have independent team ownership?

  • Not “Team A owns the backend” but “Team Trading owns the entire trading stack end-to-end”
  • Can teams deploy without asking permission from other teams?
  • Are teams measured on business outcomes, not technical metrics?

2. Do you have clear, stable service boundaries?

  • Not “we’ll figure it out as we go” but “these domains genuinely don’t need to talk much”
  • Have you tried creating module boundaries in the monolith first?
  • Can you draw the service map and predict cross-service calls?

3. Do you have strong DevOps culture and platform team?

  • Can every engineer deploy with confidence?
  • Is there a platform team providing service mesh, observability, CI/CD as a product?
  • Do you have on-call rotation and incident response practices?

4. Is your team structure aligned with the architecture?

  • Not “we’ll reorganize after migration” but “our teams are already structured for independence”
  • Does your org chart match your intended service boundaries?

If you answered “no” or “not yet” to any of these, microservices will create coordination hell.

What Your Team Actually Needs

Based on what you described:

  • 40 engineers → You’re below the threshold where microservices make organizational sense
  • Database slowdowns → This is a data layer problem, not an architecture problem
  • Deployment anxiety → This is a CI/CD and testing problem, not an architecture problem
  • Onboarding complexity → Better module boundaries (in the monolith) solve this

The board pressure is real, but it’s coming from someone who worked at Netflix. Netflix has 1,000+ engineers and genuinely independent products (recommendations, playback, billing, content). You have 40 engineers and one product.

How to Have the Board Conversation

Frame it around team effectiveness and business outcomes:

“We evaluated the microservices question. Based on CNCF research, benefits require 10-15 engineers per service with clear domain boundaries. We have 40 engineers for one integrated platform.”

“A migration would consume 12-18 months of engineering capacity with high risk to feature velocity. Instead, we’re investing in modular architecture, database optimization, and deployment improvements—all of which improve outcomes without the distributed systems tax.”

“When we reach 80-100 engineers with clear product domains, we’ll revisit this. Right now, the ROI isn’t there.”

The Real Question

Architecture decisions are team decisions. The question isn’t “Can our infrastructure handle microservices?” It’s “Can our organization handle microservices?”

For most teams under 50 engineers, the honest answer is no. And that’s fine. Make your monolith excellent. Extract services only when the pain forces your hand.

You’ll know when you’re ready—not because the board asks, but because your engineers are constantly blocked by the monolithic structure. You’re not there yet.

5

Coming at this from the product side—and I think that’s the perspective that’s most important here, even though it’s often missing from architecture debates.

The Question Nobody’s Asking

What customer problem does migrating to microservices solve?

I’ve sat through dozens of engineering architecture reviews, and this question almost never comes up. Instead, it’s: “How will we scale?” “What’s the modern approach?” “What would Netflix do?”

But customers don’t care about your architecture diagram. They care about:

  • Can I execute trades quickly? (latency)
  • Is my portfolio data accurate? (reliability)
  • Do you ship the features I’ve been requesting? (velocity)

None of those map cleanly to “monolith vs microservices.”

A Story From My Last Company

We were a Series B fintech startup (sound familiar?). Engineering team wanted to migrate to microservices. Pitched it to the exec team as “necessary for scale.”

I asked: “What’s the customer-facing impact?”

Engineering: “We’ll be able to scale better.”
Me: “Are customers complaining about performance?”
Engineering: “Not yet, but they will.”
Me: “What are they actually complaining about?”
Engineering: “…missing features, mostly.”

We had a product roadmap backlog of 18 months. Our NPS was dropping because we were shipping too slowly. And engineering wanted to spend the next 12-18 months on infrastructure.

The Business Reality Check

Let’s talk numbers:

  • Migration cost: 12-18 months of reduced feature velocity
  • Opportunity cost: What could you ship in that time?
  • Risk: Performance might get worse (see Maya’s story above)
  • Complexity cost: Ongoing operational overhead forever

ROI: Better architecture (maybe)

When you frame it this way to a CFO or board, the answer becomes obvious. Amazon Prime Video cut costs 90% by moving TO a monolith. That’s not a rounding error—that’s the difference between profitability and burning cash.

What Investors Actually Care About

That ex-Netflix engineer on your board? They’re pattern-matching to their experience at a company with:

  • 1,000+ engineers
  • Multiple independent product lines
  • Billions in revenue
  • Massive scale requirements

You have:

  • 40 engineers
  • One platform
  • 2M users (impressive, but not Netflix scale)

Investors care about:

  1. Growth metrics (are you acquiring and retaining users?)
  2. Unit economics (does each customer make you money?)
  3. Competitive positioning (are you winning vs competitors?)

Guess what doesn’t show up in those metrics? Your architecture choice.

The Framework I Use With Engineering Teams

When engineering proposes a large technical investment, I ask:

1. What customer problem does this solve?
If the answer is “none directly,” red flag.

2. What business outcome improves?
Faster features? Lower costs? Better reliability? Quantify it.

3. What’s the opportunity cost?
What won’t we ship while doing this?

4. Can we prove the hypothesis smaller?
Can we extract one service and measure the impact first?

For your situation Luis, I’d challenge the team:

  • Can we prove the database bottleneck needs microservices? Or can we fix it with indexes and replicas?
  • Can we prove deployment anxiety needs microservices? Or can we fix it with better CI/CD?
  • Can we prove the onboarding problem needs microservices? Or can we fix it with better module boundaries?

Your Conversation With the Board

Here’s how I’d frame it:

“We evaluated microservices. Industry research shows it requires 50+ engineers and clear domain boundaries to see positive ROI. We’re at 40 engineers with one integrated product.”

“The migration would take 12-18 months. Our backlog is full of customer-requested features. Our competitors are shipping. We’d essentially hand them the market while we refactor.”

“Instead, we’re investing in modular architecture, database optimization, and deployment improvements. These solve the real customer pain points—performance and feature velocity—without the distributed systems cost.”

“We’ll revisit microservices when we’re at 80+ engineers with truly independent product lines. Right now, it’s premature optimization with massive opportunity cost.”

And if they push back? Ask them to explain the ROI in business terms. Not engineering elegance. Business terms.

Bottom Line

Architecture is a means, not an end. The end is: solve customer problems profitably.

Right now, your customers need features and reliability. Microservices won’t give you that faster—it’ll slow you down. Make the pragmatic choice, not the fashionable one.