Cassandra Architecture Overview

Cassandra's architecture is designed so that every node in the cluster is equal. There is no master node, no leader, and no single point of control. This peer-to-peer design is what gives Cassandra its remarkable reliability and scale.

The Ring Architecture

Picture a clock with numbers around its edge. In Cassandra, nodes sit around a ring just like the numbers on a clock face. Each node owns a slice of that ring and is responsible for storing a specific range of data. When data arrives, Cassandra calculates which slice it belongs to and sends it to the right node automatically.

           [Node A]
          /         \
   [Node D]         [Node B]
          \         /
           [Node C]

Each node owns a token range on the ring.
Data is routed based on a hash of the partition key.

Key Components of the Architecture

1. Node

A node is a single machine (physical or virtual) running the Cassandra process. It stores data, handles read and write requests, and communicates with other nodes. You can have as few as one node for learning, or thousands of nodes in a production cluster.

2. Rack

A rack is a logical grouping of nodes, usually matching a physical rack of servers in a data center. Cassandra places data copies on nodes in different racks so that a hardware failure affecting one rack does not cause data loss.

3. Data Center

A data center in Cassandra terms is a collection of racks. You can have multiple data centers in different geographic locations. Cassandra replicates data across data centers so your application stays available even if an entire facility goes offline.

4. Cluster

The cluster is the top-level container. It holds all data centers, racks, and nodes. All nodes in a cluster share the same ring and work together to serve requests.

CLUSTER
└── Data Center 1 (e.g., US-East)
│     ├── Rack 1
│     │     ├── Node A
│     │     └── Node B
│     └── Rack 2
│           ├── Node C
│           └── Node D
└── Data Center 2 (e.g., EU-West)
      ├── Rack 1
      │     ├── Node E
      │     └── Node F
      └── Rack 2
            ├── Node G
            └── Node H

How a Write Request Travels

When your application sends a write request, any node in the cluster can receive it. That receiving node is called the coordinator for that request. The coordinator does not need to store the data itself. It calculates the correct target nodes using a partition key hash and forwards the write to them. The coordinator then waits for enough nodes to confirm the write and sends a success response back to your application.

Application
    │
    ▼
[Coordinator Node]  ◀── receives write
    │
    ├──▶ [Replica Node 1] ── writes data
    ├──▶ [Replica Node 2] ── writes data
    └──▶ [Replica Node 3] ── writes data
    │
    ▼
Application ◀── success confirmed

How a Read Request Travels

A read request arrives at any node, which again acts as coordinator. The coordinator contacts the replica nodes that hold the requested data and returns the most up-to-date result to the application. Cassandra uses timestamps to determine which copy is freshest when replicas return different versions of the same row.

Commit Log, MemTable, and SSTable

Cassandra uses a three-step write path to keep data safe and writes fast.

Step 1: Commit Log

Every write goes to a commit log on disk first. This log acts as a safety net. If a node crashes mid-write, Cassandra replays the commit log on restart and recovers the data.

Step 2: MemTable

Cassandra also writes the data into a MemTable, which is an in-memory structure. Reading from memory is extremely fast, so recent writes are served almost instantly.

Step 3: SSTable

When the MemTable fills up, Cassandra flushes it to disk as an SSTable (Sorted String Table). SSTables are immutable — once written, they do not change. Cassandra compacts multiple SSTables together periodically to keep read performance healthy.

Write Request
     │
     ├──▶ Commit Log (disk) — for crash safety
     └──▶ MemTable (RAM)    — for fast reads
                │
          [when full]
                │
                ▼
           SSTable (disk) — permanent storage

Gossip Protocol

Nodes in a Cassandra cluster communicate using a gossip protocol. Every second, each node exchanges state information with up to three other nodes. This peer-to-peer chatter lets every node learn about the health and status of every other node in the cluster — without any central coordinator.

Partitioner

The partitioner decides how Cassandra distributes data around the ring. The default partitioner (Murmur3Partitioner) uses a hashing function to convert a partition key into a numeric token. That token determines which node stores the data. This spreads data evenly across all nodes so no single node becomes a bottleneck.

Summary

Cassandra's architecture places every node on equal footing. Data travels in a ring, gets replicated across multiple nodes, and is written through a commit log and MemTable before landing on disk as an SSTable. Nodes gossip to stay aware of each other's health, and the partitioner ensures data distributes evenly. This design gives Cassandra its ability to scale without any single point of failure.