Conference Talk

# The Monolith Strikes Back
## Why We Reversed Our Microservices Migration (And Saved $1.2M)
**Emma Nakamura | Staff Engineer, Threadline**

---

# About Me

**Emma Nakamura** - Staff Engineer at Threadline

- Building distributed systems for 12 years
- Previously at Stripe (Payments Infrastructure) and Datadog (Metrics Pipeline)
- Led Threadline's original microservices migration in 2021
- And then led the partial reversal in 2024

*Yes, I migrated to microservices and then migrated parts back. This is that story.*

---

# The Problem

In 2021, Threadline was a **$40M ARR SaaS platform** running on a single Rails monolith.

- **Deploy queue:** 45 minutes to deploy, 12 deploys per day max
- **Team coupling:** 6 teams stepping on each other in the same codebase
- **Scaling limits:** Database bottleneck at 8,000 requests/second
- **Incident rate:** 3.2 customer-facing incidents per week

The obvious answer? Microservices. **So that is what we did.**

---

# Why It Matters

Our microservices migration was technically successful. We decomposed into **34 services** across 6 teams.

But by 2023, we had new problems:

- **Infrastructure costs tripled** from $180K to $540K per month
- **Latency increased 40%** due to inter-service communication overhead
- **Debugging became archaeology** - tracing a request across 8 services
- **Developer onboarding time doubled** from 2 weeks to 4 weeks
- **Each service needed its own ops** - 34 services meant 34 CI pipelines, monitoring setups, and runbooks

We had traded one set of problems for a more expensive set.

---

# Our Approach

We did not go back to a monolith. We did something more nuanced.

**The "right-sized services" approach:**

- Identified which services genuinely needed to be independent (3 out of 34)
- Consolidated the rest into **4 domain-oriented services** instead of 34 fine-grained ones
- Kept the service boundaries that aligned with **team boundaries**, not technical boundaries
- Invested heavily in the **modular monolith** pattern for consolidated services

We went from 34 services to 7 over 8 months.

---

# The Migration in Practice

**What we consolidated:**

- 12 "data access" services became 1 unified data layer
- 8 "feature" services merged into 2 domain services (billing, content)
- 6 internal API services collapsed into the main application
- 5 notification/messaging services became 1 event processing service

**What stayed separate:**
- Real-time streaming (genuinely different scaling needs)
- Search indexing (Elasticsearch, different tech stack)
- Media processing (CPU-intensive, burst scaling)

The key question for each service: *"Does this need to scale, deploy, or fail independently?"* If not, it went back.

---

# Before and After

**Before (34 services):**
- Monthly infra cost: $540K
- p99 latency: 420ms
- Deploy frequency: 180/week (but fragmented)
- Incidents/week: 2.8
- Onboarding time: 4 weeks
- Services per engineer: 4.2

**After (7 services):**
- Monthly infra cost: $195K (**64% reduction**)
- p99 latency: 180ms (**57% faster**)
- Deploy frequency: 95/week (focused)
- Incidents/week: 0.9
- Onboarding time: 1.5 weeks
- Services per engineer: 0.9

---

# Lessons Learned

- **Microservices are not a goal.** They are a tool for specific scaling and organizational problems. If you do not have those problems, you are buying complexity for free.
- **Team topology should drive architecture**, not the other way around. We had 34 services for 6 teams. The math never worked.
- **Network calls are not free.** Every service boundary adds latency, failure modes, and debugging complexity. Choose them wisely.
- **Modular monoliths are underrated.** Clear module boundaries inside a single service give you most of the organizational benefits without the operational overhead.
- **It is okay to reverse course.** The best engineering cultures treat architecture as an experiment, not a religion.

---

# Key Takeaways

- **Right-size your services** - Not everything needs to be a separate service. Ask: does it need to scale, deploy, or fail independently?
- **Measure the real cost** - Infrastructure, latency, debugging time, onboarding complexity. Microservices have hidden taxes.
- **Align architecture with teams** - One team, one or two services. If the ratio is inverted, you have a problem.
- **Modular monolith first** - Start with clear module boundaries inside a monolith. Extract to services only when you hit real limits.
- **Total savings: $1.2M/year** in infrastructure alone, plus faster development velocity

---

<!-- invert -->

# Thank You

**Emma Nakamura**

- Blog post with full technical details: threadline.dev/blog/monolith-strikes-back
- Slides: slidepicker.com/p/monolith-talk
- Twitter/X: @emma_nakamura
- Email: emma@threadline.dev

**Questions?**