BeCuriouzLearn something new every day
The team that deleted its microservices — on purpose
💡 Microservices trade runtime isolation for operational overhead — and when you have hundreds, that maintenance cost can outweigh the isolation you bought.
In a widely-read engineering post, Segment described splitting its data pipeline into a separate microservice for each destination it sent data to. On paper this was textbook: fault isolation meant one slow destination couldn't back up the others. But it quietly metastasized. Each new destination meant a new service, a new queue, and a new repo — until they were maintaining 140+ services that all needed individual tuning, deploys, and monitoring.
The killer wasn't runtime speed — it was operational overhead. A single shared library change had to be rolled out across every repo by hand. On-call engineers drowned in per-service quirks. The isolation they'd bought was real, but the human cost of running all those services had outgrown the benefit it provided.
So they did the un-trendy thing: they collapsed the fleet back into a single monolithic service (which they called Centrifuge). They gave up some perfect isolation and re-engineered fairness inside one system instead of across hundreds. The lesson isn't "monoliths good, microservices bad" — it's that architecture has a carrying cost, and past a certain point that cost can quietly exceed what the design was supposed to save you.