Skip to content

CONCEPT Cited by 2 sources

Monolith vs microservices pendulum

Definition

The observed oscillation of engineering orgs between monolith and microservices architectures as they grow, stall, or reorganize — with neither pole being a destination. A team that decomposed a monolith into services often finds itself years later introducing "macroservices" (fewer, bigger services) or a unified GraphQL data-access layer that effectively re-consolidates the logical API surface.

Canonical 2022 datapoints

  • Airbnb (Source: sources/2022-07-11-highscalability-stuff-the-internet-says-on-scalability-for-july-11th-2022):
    • 2008–2017 monolith + monorepo, ~$2.6B revenue.
    • 2017–2020 microservices (split by dedicated migration team).
    • 2020–present "micro + macroservices": unified APIs, central data aggregator, service-block facade APIs. Thrift → GraphQL as the unified data access layer.
  • Shopify — still runs a Ruby monolith, decomposing internally for developer productivity rather than splitting into services (Shopify engineering).
  • Stack Overflow — 14-year .NET monolith, 1.3B views/month on 9 on-prem servers; removed fragment cache years ago with no measurable latency impact (systems/stack-overflow-architecture).
  • Wave — $1.7B company, 70 engineers, "a Python monolith on top of Postgres."
  • Steven Lemon — "rather than separate our monolith into separate services, we started to break our solution into separate projects within the existing monolith."

2024 Uber datapoint — the 2011→2014→2018→2020 pendulum

The textbook real-world instance on this wiki. Per Josh Clemm's 2024-03-14 retrospective (sources/2024-03-14-highscalability-brief-history-of-scaling-uber):

  • 2009 → 2011: LAMP monolith → PHP/MySQL.
  • 2011: two-monolith — dispatch (Node.js) + API (Python).
  • 2013–14: SOA decomposition of the API monolith into ~100 Python/Tornado microservices, with the whole service-oriented architecture platform built to support the split (TChannel, Hyperbahn, Thrift, Clay, Flipr, M3, Jaeger).
  • 2018: The pendulum swings back toward consolidation. Uber's 2018 Project Ark response to the distributed monolith of "thousands of microservices, 12,000 repos, 5-6 systems doing 75% the same thing" — language consolidation to Java + Go, 12,000 repos → 5 per-language monorepos.
  • 2020: Partial re-swing toward structured services with the four-layer Edge Gateway — explicit Edge / Presentation / Product / Domain service tiers. Not a return to monolith; a right-sized-services structure with clear contracts.
  • 2021+: Fulfillment Platform rewrite is a re-consolidation of the matching stack into a single NewSQL-backed platform — explicitly because the 2014-era micro-service sprawl couldn't cleanly support new flow types (reservations, batching, airport queues).

The Uber arc shows the pendulum doesn't swing just twice — over 15 years, it oscillates continuously, each swing at a different level of the stack.

Core tension

Microservices sell velocity + team independence and buy distributed-systems tax — network hops, partial failure, cross-cutting feature complexity, org-chart coupling. Monoliths sell simplicity, low latency, single-deploy and buy team contention and deploy-granularity coupling. Neither tool is universally right; the pendulum swings because the trade-offs are real in both directions.

The characteristic failure mode in either direction: "you weren't doing it right" — a self-fulfilling prophecy that prevents honest retrospective. (Source: sources/2022-07-11-highscalability-stuff-the-internet-says-on-scalability-for-july-11th-2022).

Heuristics from practitioners

  • jedberg (HN): "every startup I advise I tell them don't do microservices at the start. Build your monolith with clean hard edges between modules and functions so that it will be easier later, but build a monolith until you get big enough that microservices is actually a win."
  • @hkarthik: "The longer an engineer works in a monolith, the more they yearn to decompose it into micro-services. The longer an engineer works across a ton of micro-services, the more they yearn for the days of working in a monolith."
  • @jpetazzo (OH): "we have over 170 microservices, because our principal engineer is very knowledgeable about distributed systems."

Key insight

Right-sizing services is a continuous problem, not a destination. A monolith can be properly service-based on the inside without being distributed on the outside. The count of repos means nothing; what matters is internal code organization and API boundaries.

Last updated · 517 distilled / 1,221 read