# To Microservices and Back Again - Why Segment Went Back to a Monolith
URL:: https://www.infoq.com/news/2020/04/microservices-back-again/
Author:: Thomas Betts
## Highlights
> Microservices were first introduced to address the limited fault isolation of Segment's monolith. However, as the company became more successful, and integrated with more external services, the operational overhead of supporting microservices became too much to bear. The decision to move back to a monolith came with a new architecture that considered the pain points around scaling related to company growth. While making sacrifices in modularity, environmental isolation, and visibility, the monolith addressed the major issue of operational overhead, and allowed the engineering team to get back to new feature development. ([View Highlight](https://read.readwise.io/read/01fddpjw782g999a27j71t1r6j))
> Noonan pointed out the limitations of a one-size-fits-all approach to their microservices. Because there was so much effort required just to add new services, the implementations were not customized. One auto-scaling rule was applied to all services, despite each having vastly different load and CPU resource needs. Also, a proper solution for true fault isolation would have been one microservice per queue per customer, but that would have required over 10,000 microservices. ([View Highlight](https://read.readwise.io/read/01fddpkc2jt9zastdryktck885))
---
Title: To Microservices and Back Again - Why Segment Went Back to a Monolith
Author: Thomas Betts
Tags: readwise, articles
date: 2024-01-30
---
# To Microservices and Back Again - Why Segment Went Back to a Monolith
URL:: https://www.infoq.com/news/2020/04/microservices-back-again/
Author:: Thomas Betts
## AI-Generated Summary
When Segment moved to a microservices architecture, they gained environmental isolation, but at a cost of higher operational overhead. Three years later, the costs were too high, and the team migrated back to a monolith. At QCon London, Alexandra Noonan told the cautionary tale, and emphasized the importance of evaluating trade-offs in architectural decisions.
## Highlights
> Microservices were first introduced to address the limited fault isolation of Segment's monolith. However, as the company became more successful, and integrated with more external services, the operational overhead of supporting microservices became too much to bear. The decision to move back to a monolith came with a new architecture that considered the pain points around scaling related to company growth. While making sacrifices in modularity, environmental isolation, and visibility, the monolith addressed the major issue of operational overhead, and allowed the engineering team to get back to new feature development. ([View Highlight](https://read.readwise.io/read/01fddpjw782g999a27j71t1r6j))
> Noonan pointed out the limitations of a one-size-fits-all approach to their microservices. Because there was so much effort required just to add new services, the implementations were not customized. One auto-scaling rule was applied to all services, despite each having vastly different load and CPU resource needs. Also, a proper solution for true fault isolation would have been one microservice per queue per customer, but that would have required over 10,000 microservices. ([View Highlight](https://read.readwise.io/read/01fddpkc2jt9zastdryktck885))