Apache Cassandra

Web giants hit a wall. Facebook, with hundreds of millions of users, must handle a seemingly simple feature: inbox search. But beneath this simplicity lies a formidable technical challenge. Every day, billions of writes flood into the systems, and growth shows no sign of slowing down. Traditional databases, designed in the 1970s, reveal their limitations when faced with these volumes.

Avinash Lakshman and Prashant Malik set out to create a new solution to address the problem. Lakshman doesn’t come empty-handed; he participated at Amazon in designing Dynamo, a distributed storage system that serves as a reference. Their insight is to combine two previously distinct approaches. On one side, the architectural principles of Dynamo that have proven themselves at Amazon. On the other, the data model of BigTable, Google’s in-house solution. From this meeting, Cassandra is born, named after the prophetess of Greek mythology.

In July 2008, Facebook makes a decision that will change the game. Rather than jealously guarding its code, as Google and Amazon do by merely publishing papers describing their architectures, the social network releases Cassandra’s entire source code under the Apache license. The gesture marks a break from the practices of technology companies. The following year, the project joins the Apache Foundation incubator, before achieving in February 2010 the coveted status of top-level project.

Cassandra’s architecture breaks with established patterns. Where classic databases organize themselves according to a master-slave hierarchy, Cassandra adopts a model where all nodes play the same role. No conductor, no single point of failure. Data distributes automatically among participating machines, and the system scales horizontally without requiring an administrator to intervene. This total decentralization guarantees continuous availability, even when some nodes fail.

Data redundancy is embedded in the system’s DNA. Cassandra automatically replicates information across multiple nodes. The administrator simply indicates the desired number of copies, the rest happens automatically. If a machine fails, the data remains accessible elsewhere. This approach, simple in principle, proves effective in practice.

Netflix offers a compelling example of what Cassandra makes possible. In 2011, the streaming service deploys a cluster of 288 instances in the cloud. The system handles 1.1 million writes per second coming directly from clients. With replication across three different availability zones, this figure climbs to 3.3 million writes per second. These performances would have been unthinkable a few years earlier with conventional technologies.

The arrival of the CQL language greatly facilitates adoption. Its syntax resembles that of SQL, known to millions of developers worldwide. A programmer familiar with relational databases can get to grips with Cassandra without relearning everything. Certainly, differences remain: no joins for example, which reflects the system’s denormalized data model. But the entry barrier drops considerably.

The community grows rapidly. In 2012, over 1,000 production deployments are already running, from eBay to Disney and Netflix. Tools multiply, integrations with Hadoop, Spark, or Solr enrich the ecosystem. The big data world finds in Cassandra a reliable pillar.

DataStax emerges in 2010 and brings a commercial dimension to the project. The company hires the main contributors and offers an enterprise version with additional features, technical support, and administration tools like OpsCenter. The open source model finds there its viable economic counterpart.

The numbers speak for themselves. A comparative study presented at the Very Large Database conference in 2012 pits Cassandra against HBase. Read latency times prove up to 100 times faster, throughput eight times higher. These results don’t come out of nowhere: they stem directly from the initial architectural choices.

Versions follow one another and bring their share of improvements. Version 1.0 in 2011 optimizes performance and compresses data. Version 2.0 in 2013 introduces lightweight transactions via the Paxos protocol. Version 3.0 in 2015 adds materialized views. Version 4.0 in 2021 deploys zero-copy streaming and supports Java 11. Each iteration pushes the system’s capabilities a bit further.

Instagram, acquired by Meta, relies on Cassandra to manage data for over one billion active users each month. Use cases diversify: time series, real-time analysis, multimedia content management, e-commerce. Wherever volumes explode and unavailability costs dearly, Cassandra finds its place.

The impact extends beyond the purely technical dimension. Cassandra demonstrates that a database can combine high availability, linear scalability, and high performance. These three pillars respond exactly to the needs of contemporary web applications, where every minute of downtime counts in millions and where data never stops growing.

Cassandra finds favorable ground in hybrid and multi-cloud deployment. The system operates transparently across multiple data centers or different cloud providers. While keeping their data consistent, companies thus escape dependence on a single vendor.

Other projects draw inspiration from Cassandra. ScyllaDB incorporates its concepts in C++ to gain even more performance. The decentralized architecture and tunable consistency model now serve as a reference in the field of distributed storage.

Twenty years after its birth, Apache Cassandra remains a cornerstone of the NoSQL ecosystem. Its story tells of the maturation of distributed architectures and their capacity to adapt to the ever-increasing demands of modern applications. What began as an internal solution at Facebook has become a de facto standard for anyone who must manage massive data with strict availability guarantees.