Why Twilio Segment moved from microservices back to a monolith

Original Article ↗ Hacker News Discussion ↗

Article timing & context

  • Many point out the post is from 2018 and argue its lessons predate today’s tooling, patterns, and AI assistance.
  • Others say the age is still relevant: it documents a common failure mode of “microservices done badly,” not an obsolete technical detail.

What “microservices” actually are

  • Strong debate over definitions: some argue microservices are about independently deployable services aligned to business capabilities, not about infra, HTTP, or multiple machines.
  • Others push back on authority-based definitions and note the term’s history from SOA, saying most real systems don’t meet the “pure” ideal anyway.
  • Several stress that if services can’t be deployed independently, you’ve built a “distributed monolith,” not microservices.

Shared libraries, coupling & distributed monoliths

  • The Segment case where a shared library forced redeploys across ~140 services is widely criticized as tight coupling that defeats microservice benefits.
  • Thread dives into nuances:
    • Some say any shared dependency with lockstep upgrades = distributed monolith.
    • Others argue shared deps are fine if consumers can pin versions and upgrades are backward compatible.
    • There’s a long subthread on protobuf/JSON schemas and backward compatibility vs version sprawl and tech debt.

Org structure, discipline & culture

  • Many see the real root cause in organizational issues: weak technical leadership, lack of “someone who can say no,” and Conway’s/Peter/Parkinson effects.
  • Argument that microservices are primarily an org-scaling tool; using them with a tiny team (3 people, 140 services) is self-sabotage.

Monolith vs microservices trade-offs

  • Multiple commenters emphasize both patterns can work or fail; dogmatism is the real problem.
  • Monolith advantages cited: easier refactoring, simpler wide-scale upgrades (e.g., security patches), fewer distributed-systems failure modes, better end-to-end understanding.
  • Microservice advantages cited: team decoupling, isolated deployments, clearer ownership, better fit for many heterogeneous integrations.

Testing, tooling & repos

  • A lot of the Segment story is reframed as test-quality and repo-layout problems rather than architecture per se.
  • Several suggest monorepos with good tooling (Bazel, dependency-based test selection) can keep services independent while solving many of the pain points they hit.