# The Single Point of Failure

DevFeed: [The Single Point of Failure](<https://devfeed.tech/articles/the-single-point-of-failure-33401.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2013/06/09/dist-sys-antipatterns>)

Published: 2013-06-09T00:00:00Z

Content type: opinion

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Server](<https://devfeed.tech/topics/server.md>), [MongoDB](<https://devfeed.tech/topics/mongodb.md>), [Replication](<https://devfeed.tech/topics/replication.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [backend](<https://devfeed.tech/tags/backend.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [distributed-system](<https://devfeed.tech/tags/distributed-system.md>), [mongodb](<https://devfeed.tech/tags/mongodb.md>), [replication](<https://devfeed.tech/tags/replication.md>)

## AI overview

The article explains how a manually configured master service can become a single point of failure and bottleneck in a distributed system. It uses MongoDB's automatic master election and replication as a less naive approach, while noting that failover can still leave the cluster temporarily unable to coordinate work.

## Source excerpt

Recently I've been mentoring a startup in the Boulder area that processes large amounts of data real time. They have a Service Oriented Achitecture in which backend services do most of the data processing. While they were still in beta they were getting spikes of traffic, which led us to a conversation that went like: