Why We Abandoned Microservices: Lessons from Scaling a High‑Throughput Event Pipeline

Microservices have become a popular architectural style, and Segment adopted them early. While the approach helped in many scenarios, the team eventually hit serious problems as the system grew.

Microservice Advantages

Segment’s customer‑data infrastructure processes tens of thousands of events per second and forwards them to more than a hundred destination APIs (e.g., Google Analytics, Optimizely). Initially the architecture was simple: an API received events, placed them on a distributed message queue, and a single worker consumed them.

When an event is consumed, the system checks the customer’s configuration to decide which destinations should receive the event, then sends the event sequentially to each destination’s API. If a request fails, the system may retry later. Retry‑able errors include HTTP 500, rate‑limit, and timeouts; non‑retryable errors include invalid credentials or missing required fields.

Because each destination had its own queue, a slow or failing destination could block the head of the queue, causing latency for all destinations.

Reason for Independent Repositories

Each destination API uses a different request format, requiring custom code to map event fields. For example, destination X expects traits.dob while Segment’s API accepts traits.birthday. When all destinations lived in a single repository, a failure in one test caused the entire suite to fail, slowing down deployments.

Splitting each destination into its own repository isolated test suites and allowed teams to work on a destination without affecting others.

Scaling Microservices and Codebases

As the number of destinations grew to over 50, the team created a shared library to handle common transformations (e.g., extracting a user’s name). The library checks several possible field names ( name, Name, firstName, first_name, FirstName) and falls back accordingly. This reduced duplication when adding new destinations.

However, changes to the shared library now impacted every destination. Deploying a new version required testing and releasing dozens of services, a high‑risk operation. Over time, different destinations began using different versions of the shared library, leading to fragmentation and increased maintenance overhead.

Load patterns also varied: some services processed a few events per day, while others handled thousands per second. Manual scaling was required for low‑traffic services when unexpected spikes occurred, and automatic scaling configurations differed per service, making scaling more of an art than a science.

Abandoning Microservices and Queues

Faced with over 140 services, the team decided to merge them into a single service with a shared queue. This eliminated the head‑of‑queue blockage and reduced operational overhead.

The new architecture processes all events in one queue and uses a single destination processor to handle them. It retains the benefits of the shared library while simplifying deployment, testing, and resource management.

As a result, operational costs dropped, latency improved, and developers could focus on delivering customer value instead of fighting infrastructure complexity.

The journey demonstrates that microservices are not a one‑size‑fits‑all solution; for certain workloads and team sizes, a monolithic or simplified architecture can be more efficient and manageable.