Segment merged over 140 microservices back into one

transcript

Segment had over 140 microservices. Then merged them all into one. And splitting them had fixed a real problem. So why go back?

Segment forwards hundreds of thousands of events a second. To over a hundred kinds of destinations. All through one queue. One destination slows down. Its retries flood the queue. Now delivery gets slower for every destination.

The fix: each destination gets its own service and queue. It worked. Then it grew. About three new destinations a month. Shared libraries drifted. Updating one meant testing and deploying dozens of services. On-call got paged for load spikes. 3 engineers mostly just kept it alive.

So they went back. Over 140 services became one. A new system, Centrifuge, replaced the per-destination queues. One repo. One version of each of 120 dependencies. Tests hit real partner APIs, slow and flaky. Now they replay saved responses.

Shared-library improvements in the microservices era: 32. In the year after the merge: 46. One engineer deploys in minutes.

But here's the catch. One destination's bug can now crash them all. And in-memory caches work less well across 3,000-plus processes.

Microservices are a trade, not a default. When isolation costs more than it's worth, merging back can be right.

Full breakdown in the lecture.