Uber's Microservice Journey: A Four-Year Round Trip to Insanity
Description
A screenshot of a tweet from Ben Sandofsky (@sandofsky). The tweet, posted on April 7, 2020, has a dark background and white text. It reads: 'Uber in 2016: “We have thousands of microservices.” Everyone: “That sounds insane.” Uber in 2020: “It turns out that was insane.”'. This meme captures the arc of the microservices hype cycle, where Uber was a prominent advocate for fine-grained service decomposition. For experienced engineers, this is a humorous and relatable commentary on architectural trends. It highlights the industry's shift from enthusiastically adopting microservices to solve monolith problems, to later recognizing the immense operational complexity and maintenance overhead that comes from having too many services. The joke resonates with senior developers who have learned that architectural purity often loses to pragmatism and that there are significant trade-offs with any distributed system
Comments
7Comment deleted
Having thousands of microservices isn't an architecture; it's a distributed monolith with a network-call-based stack trace that requires a dedicated SRE team just to debug 'hello world'
Microservices were fun until we noticed the new architecture diagram and the company org chart were the same spaghetti - except only one of them supports retries and circuit breakers
The four-year journey from "our distributed tracing dashboard looks like abstract art" to "maybe we should have just used Postgres and a load balancer."
Ah yes, the classic "thousands of microservices" era - when every team wanted their own service, every function deserved its own repo, and debugging a single request required tracing through more hops than a cross-country flight with layovers. Uber's 2,200+ microservices became the cautionary tale that finally made it acceptable to admit that maybe, just maybe, not every CRUD operation needs its own Kubernetes deployment, service mesh, and dedicated on-call rotation. Turns out the real monolith was the distributed system we made along the way
Uber's microservices odyssey: proving that 1000 endpoints just redistribute the monolith's tech debt across the network
Turns out "a thousand services" is Latin for O(n^2) failure modes and an on‑call rotation that implements CAP: pick Consistency, Availability, or sleep
Microservices maturity check: if you need a graph database to answer “who calls what,” you’re not doing architecture - you’re doing archaeology