The encyclopedia · Software & IT · Technical decision · 2008–2010
Cassandra kept Facebook's Inbox Search writable through failures and data-center splits
A Bigtable-like column model over Dynamo-style quorums let Cassandra absorb billions of daily writes with no single point of failure.
the move
Facebook's Inbox Search needed to handle billions of writes per day and scale with hundreds of millions of users, served from geographically distributed data centers. On an infrastructure where small and large components fail continuously, the storage layer had to treat failure as the norm rather than the exception.
Cassandra combined proven techniques: Dynamo-style partitioning, quorum-based replication and gossip for membership and failure detection, with a Bigtable-like column-family model. There is no single master and no single point of failure, so reads and writes keep working through outages, and data replicates across data centers to keep search latency low.
Inbox Search launched on Cassandra in June 2008 for about 100 million users and grew past 250 million users by the time the LADIS paper was written; Cassandra also became the backend for multiple other Facebook services.
why it works
- No master means any node can serve reads and writes
- Quorum replication keeps availability during node failures
- Gossip-based membership scales to hundreds of nodes
- Column-family model fits high-volume semi-structured data
what transfers
When a product must never stop writing, design the storage for failure: decentralize authority, replicate across data centers, and let consistency be tuned rather than absolute.
what came after
Facebook contributed Cassandra to the Apache Foundation, and the project's site describes an open-source NoSQL database trusted by thousands of companies for linear scalability and proven fault tolerance on commodity hardware, with Netflix and Bloomberg among the named users.
references
spotted an error? The archive wants to know.