Why We Dropped 140+ Microservices for a Single Monolith—and What We Learned

Why Microservices Seemed Viable at First?

Segment's customer‑data platform ingests hundreds of events per second and forwards each event to a "destination" such as Google Analytics, Optimizely, or custom webhooks. Initially the architecture was a simple message queue that received JSON events like:

{
  "type": "identify",
  "traits": {
    "name": "Alex Noonan",
    "email": "[email protected]",
    "company": "Segment",
    "title": "Software Engineer"
  },
  "userId": "97980cfea0067"
}

Events were consumed from the queue and routed to the appropriate destination API. When a request failed, retries were sometimes safe (e.g., 5xx errors, rate limits) and sometimes not (e.g., authentication errors).

Because retries accumulated in the same queue, a slow or failing destination could block the entire queue, causing latency spikes for all destinations.

Personal Repo Example

Each destination has a different request format, requiring custom conversion code. For example, destination X expects a field dob while the incoming event uses birthday:

const traits = {};
traits.dob = segmentEvent.birthday;

Initially all destination code lived in a single repository, causing a single test failure to break the whole project. To isolate failures, each destination was split into its own repo, but this introduced new testing and deployment overhead.

Scaling Microservices and Repos

With over 50 new destinations added, a shared library was created for common functionality such as HTTP handling. Example utility for extracting a user's name:

Identify.prototype.name = function() {
  var name = this.proxy('traits.name');
  if (typeof name === 'string') {
    return trim(name);
  }
  var firstName = this.firstName();
  var lastName = this.lastName();
  if (firstName && lastName) {
    return trim(firstName + ' ' + lastName);
  }
};

While the shared library reduced duplication, any change required retesting and redeploying dozens of services, creating a heavy maintenance burden.

Building an Elastic Test Suite

To speed up testing, a "Traffic Recorder" based on yakbak was built. It records HTTP requests on the first test run and replays the saved responses on subsequent runs, eliminating external network dependencies.

After integrating the recorder, the full test suite for 140+ destinations ran in milliseconds instead of minutes.

Why a Monolith Became Viable

By merging all destination code into a single repository, developers could deploy changes across all services in seconds, dramatically improving iteration speed. The unified service also simplified scaling: a large process pool could absorb traffic spikes without the need to manage dozens of tiny services.

Drawbacks of the Monolith

1. Fault isolation is harder—if one destination crashes, it can bring down the entire service. 2. Cache efficiency drops because many low‑traffic destinations now share a large pool of processes, reducing hit rates. 3. Updating the shared library can still cause multiple destinations to fail, though automated tests mitigate the risk.

Conclusion

Segment's original microservice architecture solved early performance problems but later became a source of operational overhead. Consolidating into a single monolithic service restored developer productivity and simplified scaling, though it introduced new challenges around fault isolation and caching.