Cassandra architecture overview

Ideas you will meet

Databases

Schemas, indexes, query plans and choosing a store.

Replication

Leader/follower, multi-leader and leaderless replication.

Consistency Models

Linearizable, causal and eventual consistency explained.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Databases Deep Dive · 12 minReplication topologies and multi-region databasesSingle-leader, multi-leader and leaderless replication, how they handle conflicts and lag, and what changes across regions.Read hereClose

  Why replicate

  Replication keeps copies of data on several machines for three reasons: availability (survive a node failure), read scaling (serve reads from replicas) and latency (put data near users). The hard part is keeping copies consistent while writes continue. (Basics are in the replication and sharding lesson of the foundations course; this lesson compares the topologies.)

  Single-leader (primary and replicas)

  One node, the leader (primary or master), accepts writes and ships its changes to followers (replicas), which serve reads.

  100%

  Figure SDA-DDV-04-1 · Single-leader replication · © forcsguy.com

  • Synchronous replication waits for a follower before acknowledging: safer, slower, and a stalled follower can block writes. Asynchronous is faster but a failover can lose the latest writes. A common compromise: one synchronous follower, others asynchronous.
  • Failover must detect failure, choose the most up-to-date replica, redirect clients and ensure the old leader does not come back believing it still leads (split brain).
  • Replication lag causes stale reads. Techniques: read-your-writes (route a user's reads to the leader shortly after they write), monotonic reads (keep a user on one replica), and checking replica position.

  Multi-leader

  Several nodes accept writes (often one per region) and replicate to each other. Benefits: local write latency and continued operation if a region is cut off. Cost: write conflicts.

  Conflict handling options:

  • Avoid them: route all writes for one record to one leader (for example by user or region).
  • Last write wins by timestamp: simple, but silently drops one of two concurrent updates and depends on clocks.
  • Merge values (union of sets, counters) using mergeable data types (CRDTs; see the collaborative editing lesson).
  • Custom resolution in application code, or ask the user.

  Multi-leader also appears in offline-capable apps (each device is a leader) and collaborative editing.

  Before: single leader

  100%

  After: multi-leader across regions

  100%

  What changed

  • Users in each region write to a nearby database
  • Concurrent edits to the same row need conflict handling
  • More moving parts to run and monitor

  Leaderless (Dynamo-style)

  Any replica accepts writes; clients write to several replicas and read from several, using quorums (W + R > N) to get fresh data (see the key-value store lesson). Background anti-entropy and read repair fix stale copies; versions or vector clocks detect conflicts. It favours availability and is typical of Cassandra and DynamoDB-style stores.

  100%

  Figure SDA-DDV-04-2 · Choosing a replication model · © forcsguy.com

  Multi-region designs

  • Active-passive: one region serves writes; another is a warm standby. Simple; failover loses a little data (the replication lag) and takes minutes.
  • Active-active: several regions serve traffic. Requires either partitioning data by home region (each record has one home, cross-region reads are replicas) or true multi-leader conflict handling.
  • Global databases use consensus across regions (see the consensus lesson) for strong consistency at the cost of cross-region write latency; some offer tunable consistency per query.
  • Latency numbers matter: a cross-ocean round trip is around 100 ms or more, so synchronous cross-region replication adds that to every write.
  • Data residency laws may require keeping certain users' data in a region.

  Partitioning and replication together

  Real systems shard data into partitions and replicate each partition (a leader per partition spreads write load across nodes). Rebalancing, hot partitions and cross-partition transactions are the new problems (see sharding and the consistent-hashing lesson).

  Master/slave naming

  You will see "master/slave", "primary/replica" and "leader/follower" for the same single-leader idea; most current documentation prefers the last two.

  Checklist

  • What happens to writes if the leader or a region is lost, and how long?
  • How much data can we lose (RPO) and how long can we be down (RTO)?
  • How do we handle stale reads from replicas?
  • Who resolves conflicts, and how?
  • Have we practised failover?

  Real-world reading

  Related reading

  • Active-Active for Multi-Regional ResiliencyNetflix Engineering · NetflixCase Studies
  • Designing Data-Intensive ApplicationsMartin Kleppmann · O'ReillyBooks
  • Read Consistency with Database Replicas at ShopifyShopify engineers · ShopifyCase Studies
  • Uber Schemaless: A Scalable MySQL DatastoreUber Engineering · UberCase Studies

  Show 6 moreShow fewer

  • Mitigating MySQL Replication Lag and Reducing Read Load at GithubGithub engineers · GithubCase Studies
  • Cassandra architecture overviewApache Cassandra · Apache Software FoundationDocumentation
  • How Discord Stores Trillions of MessagesBo Ingram · DiscordBlogs
  • Spanner: Google's Globally Distributed Database (paper)Corbett et al. · GooglePapers
  • Scaling Multitenant Architecture Across Multiple Data Centres at Shopify - Weingarten, Engineering Lead at ShopifyShopifyYouTube
  • MIT 6.824: Distributed SystemsRobert Morris · MITCourses

  Open this lesson with its quiz and exercise

• Advanced Distributed Systems · 13 minKafka internals: segments, replication and consumer groupsWhat is inside a topic: partitions as append-only logs split into segments, how followers keep copies, and how consumer groups share the work.Read hereClose

  A topic is a set of logs

  A Kafka topic is split into partitions. Each partition is an append-only log: new records go on the end and get an increasing offset. Order is guaranteed only within a partition; records with the same key go to the same partition, so per-key order holds. Consumers track how far they have read by offset. (Why this design is fast is covered in the "Why is Kafka fast" lesson.)

  On disk: segments

  A partition's log is stored as a series of segment files. The newest segment is the one being written; older segments are immutable. Each segment has companion index files that map offsets (and timestamps) to positions in the file, so a consumer can jump to an offset quickly.

  • Retention is applied by deleting whole old segments (by age or total size), which is cheap.
  • Compaction (for some topics) keeps only the latest record per key, turning the log into a changelog of current state.

  100%

  Figure SDA-ADS-03-1 · Partitions, segments and replicas · © forcsguy.com

  Replication and durability

  Each partition has a replication factor (commonly 3): one leader and followers. Followers fetch from the leader. The in-sync replicas (ISR) are the followers that are caught up.

  A producer chooses an acknowledgement level:

  Setting	Meaning	Trade-off
  acks=0	Do not wait	Fastest, may lose data
  acks=1	Leader has written it	Loses data if the leader fails before replicating
  acks=all	All in-sync replicas have it	Safest, slower

  With acks=all and a minimum in-sync replicas setting, a write succeeds only if enough copies exist, trading availability for durability. If the leader fails, a new leader is chosen from the in-sync replicas, so acknowledged writes survive. (Older versions used ZooKeeper for cluster metadata; newer ones use a built-in Raft-based controller; the idea of consensus on metadata is the same as in the consensus lesson.)

  Consumer groups and rebalancing

  Consumers sharing a group id split a topic's partitions: each partition is read by one member at a time, so parallelism is limited by the number of partitions. Different groups each read the full topic independently.

  100%

  Figure SDA-ADS-03-2 · Consumer group rebalance · © forcsguy.com

  Offsets are committed back to Kafka. Commit after processing for at-least-once delivery (duplicates possible, so make consumers idempotent). Rebalances happen when members join, leave, crash or are too slow (missing heartbeats or taking too long to poll). Frequent rebalances hurt throughput, so keep processing per batch short and group membership stable.

  Practical rules

  • Partition count is a design decision: it caps consumer parallelism, and increasing it later changes the key-to-partition mapping.
  • Key choice controls ordering and balance: pick a key with many distinct values.
  • Monitor consumer lag per partition, under-replicated partitions and request latency.
  • Idempotent producers and transactions exist for stronger guarantees (exactly-once within Kafka); end-to-end exactly-once still needs idempotent consumers or transactional sinks.
  • Stream processing (Kafka Streams, Flink) builds on the same consumer mechanics; see the big-data platforms course.

  Real-world reading

  Related reading

  • Exactly-once Semantics Is Possible: Here's How Apache Kafka Does ItNeha Narkhede · ConfluentBlogs
  • Kafka Source & DocsApache Software Foundation · apacheGitHub
  • Confluent Developer: Apache Kafka 101ConfluentCourses
  • Confluent: Apache Kafka TalksConfluentYouTube

  Show 6 moreShow fewer

  • Jordan Has No Life: Systems Design Concepts SeriesJordan · Jordan Has No LifeYouTube
  • Apache Kafka DocumentationApache Kafka · Apache Software FoundationDocumentation
  • Apache CassandraApache Software Foundation · GitHubGitHub
  • Cassandra architecture overviewApache Cassandra · Apache Software FoundationDocumentation
  • REA Group Engineering BlogREA Group engineers · REA GroupBlogs
  • Repo-Topix: Topic Extraction Framework at GithubGithub engineers · GithubCase Studies

  Open this lesson with its quiz and exercise

• Big Data and Cloud Data Platforms · 11 minHow big data evolved, and the papers behind itFrom single databases to Hadoop, Spark, streaming and lakehouses: a timeline of ideas and the research papers that started each one.Read hereClose

  Why a new wave kept appearing

  Each generation of data tools answered a limit of the previous one. Understanding the problem behind each wave makes the tools easier to place.

  Image: Trower, NASA · Public domain · Source · Wikimedia Commons: Columbia Supercomputer - NASA Advanced Supercomputing Facility

  A timeline

  100%

  Figure SDA-BDP-01-1 · A timeline · © forcsguy.com

  1. Before: relational databases and data warehouses

  Data fit on one big server. SQL and data warehouses served reports. Limits: scaling up got very expensive, and unstructured data (web logs, clicks) did not fit neatly.

  2. Web scale (around 2003 to 2006)

  Search companies had far more data than any single machine could hold. Google described how it coped, and open-source projects copied the ideas.

  • GFS (Google File System): a distributed file system on commodity machines that expects failures.
  • MapReduce: a model to process huge datasets in parallel.
  • Hadoop (HDFS plus MapReduce) brought both to everyone.

  3. NoSQL (about 2006 to 2010)

  Web applications needed massive scale and high availability that relational systems struggled to give.

  • Bigtable: a sparse, sorted, wide-column store; inspired HBase and Cassandra's data model.
  • Dynamo: an always-writable key-value store with consistent hashing and eventual consistency; inspired Cassandra, Riak and DynamoDB.

  4. Faster and friendlier processing (2010 onward)

  • Dremel: interactive SQL over huge datasets using columnar storage and tree-shaped execution; the idea behind BigQuery and later engines, and the Parquet format.
  • Spark (resilient distributed datasets): keeps data in memory between steps, much faster than disk-based MapReduce for iterative work, with friendly APIs.

  5. Streaming

  Waiting for nightly batches was too slow. Kafka made a durable, replayable log the backbone of event pipelines, and engines such as Flink and the Dataflow model handled continuous computation with proper treatment of event time, windows and late data.

  6. The cloud

  Cloud providers separated storage (cheap object storage) from compute (elastic clusters or serverless queries). Managed warehouses (BigQuery, Redshift, Snowflake and others) removed cluster management.

  7. The lakehouse

  Data lakes were cheap but unreliable (no transactions, messy files). Table formats (Delta Lake, Apache Iceberg, Apache Hudi) add ACID transactions, schema evolution and time travel on top of files in object storage, so one copy of data can serve both analytics and machine learning.

  100%

  Figure SDA-BDP-01-2 · Key dates, in order · © forcsguy.com

  The classic papers

  These are the research papers most often cited. Search the title to find each; most are freely available.

  Paper	Authors (and year)	The idea
  The Google File System	Ghemawat, Gobioff, Leung (2003)	Large-file storage across commodity machines, built to tolerate failures
  MapReduce: Simplified Data Processing on Large Clusters	Dean, Ghemawat (2004)	A simple map and reduce model with automatic parallelism and fault tolerance
  Bigtable: A Distributed Storage System for Structured Data	Chang and others (2006)	A sorted, sparse, multi-dimensional map for structured data at scale
  Dynamo: Amazon's Highly Available Key-value Store	DeCandia and others (2007)	Consistent hashing, quorums, vector clocks and eventual consistency
  Dremel: Interactive Analysis of Web-Scale Datasets	Melnik and others (2010)	Columnar nested data and tree execution for fast SQL
  Kafka: a Distributed Messaging System for Log Processing	Kreps, Narkhede, Rao (2011)	A partitioned, replicated log as the backbone for event data
  Resilient Distributed Datasets (Spark)	Zaharia and others (2012)	In-memory, fault-tolerant parallel computing
  Spanner: Google's Globally-Distributed Database	Corbett and others (2012)	Strongly consistent, globally distributed SQL using synchronised clocks
  The Dataflow Model	Akidau and others (2015)	A unified model for batch and streaming with event time and windows
  Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores	Armbrust and others (2020)	Transactional tables on object storage: the lakehouse idea

  A good companion is Jay Kreps's essay "The Log: What every software engineer should know about real-time data's unifying abstraction" (2013).

  What to take away

  • Scale-out on cheap machines (GFS, MapReduce) made big data practical.
  • Availability versus consistency choices (Dynamo, Bigtable, Spanner) shaped databases.
  • Columnar storage (Dremel, Parquet) made analytics fast.
  • Logs and streams (Kafka, dataflow) made data continuous.
  • Separating storage from compute and open table formats define today's platforms.

  Real-world reading

  Related reading

  • Dremel: Interactive Analysis of Web-Scale Datasets (paper)Melnik et al. · GooglePapers
  • Cassandra architecture overviewApache Cassandra · Apache Software FoundationDocumentation
  • Fast Order Search using Data Pipeline and Elasticsearch at YelpYelp engineers · YelpCase Studies
  • Apache CassandraApache Software Foundation · GitHubGitHub

  Show 6 moreShow fewer

  • Amazon S3 strong consistencyAmazon Web ServicesDocumentation
  • Sherpa: Distributed NoSQL Key-Value Store at YahooYahoo engineers · YahooCase Studies
  • Elasticsearch GuideElasticDocumentation
  • MapReduce: Simplified Data Processing on Large Clusters (paper)Dean and Ghemawat · GooglePapers
  • HBase at SalesforceSalesforce engineers · SalesforceCase Studies
  • Columnar DatabasesAmazon Web Services engineers · Amazon Web ServicesCase Studies

  Open this lesson with its quiz and exercise