Why Uber’s Go Monorepo Strategy Nearly Broke and How They Saved It

When 3,000 Microservices Share One Repository Why Uber’s Go Monorepo Strategy Nearly Broke and How They Saved It When 3,000 Microservices Share One Repository The monorepo at scale — how Uber manages 3,000+ microservices in a single repository that processes over 1,000 commits daily while maintaining system stability. A single commit to Uber’s Go monorepo can instantly affect 3,000 microservices. When an engineer pushes a change to their shared RPC library, every service at Uber — from ride dispatching to payment processing — gets rebuilt and redeployed within hours. This architectural decision seemed brilliant until it nearly brought down their entire engineering organization. At time of writing in 2024 our Go monorepo sees more than 1,000 commits per day, and is the source for almost 3,000 microservices, which could all be affected by a single commit. The scale had outgrown their tooling, their processes, and their risk management strategies. This is the story of how Uber’s monorepo