Skip to content

CONCEPT Cited by 1 source

Distributed monolith

Definition

A distributed monolith is the anti-pattern of having successfully decomposed a monolith into many microservices — but keeping the underlying coupling intact. You pay all the operational costs of a microservices fleet (network hops, partial-failure modes, deploy orchestration, service discovery, per-service observability) while retaining the blocking-release, tight-coupling, and shared-database properties that motivated decomposing the monolith in the first place.

Coined in the mid-2010s microservices literature; the canonical warning in the category is Ben Christensen's talk Don't Build a Distributed Monolith.

Symptoms (from Uber's 2018 Project Ark)

Former Uber CTO Thuan Pham's canonical quote, cited in the 2024-03-14 retrospective:

"You've got five or six systems that do incentives that are 75 percent similar to one another." (Source: sources/2024-03-14-highscalability-brief-history-of-scaling-uber)

The symptom set Josh Clemm lists from Uber's 2018 state:

  • Thousands of microservices (from ~100 in 2014).
  • Thousands of code repositories (Uber: 12,000).
  • Multiple product solutions solving the same problem (the "5 or 6 incentive systems" quote above).
  • Multiple solutions to common engineering problems — different message-queue choices, different database choices, different communication protocols, multiple official programming languages.
  • Developer productivity hurting.

Each alone is survivable. The combination is the distributed monolith's characteristic shape.

Root cause

The distributed monolith emerges when org culture rewards local autonomy without investing in cross-team standards. Uber's "Let Builders Build" was an explicit cultural value that produced world-class product velocity — and the 2018 cleanup bill. Conway's-Law-driven: if no team owns cross-cutting standards, no cross-cutting standards get built; each team ships its own.

The cure: standardization

Uber's response to the distributed monolith was 2018 Project Ark (cited in the 2024-03-14 retrospective):

  • Java + Go as official backend languages. Python + JavaScript deprecated for backend.
  • 12,000 repos → monorepos per language.
  • Standardized architectural layers — client, presentation, product, business logic — with clear homes.
  • Service "domains" abstraction grouping related services.
  • Shared service libraries for tracing, logging, networking protocols, resiliency patterns.

This is an ongoing, never-complete cure — the pendulum swings back toward monolith-shape consolidation, and then a new tradeoff point demands partial re-decomposition. See concepts/monolith-vs-microservices-pendulum.

Last updated · 517 distilled / 1,221 read