Why Cassandra can handle massive writes without bottlenecks

Hi,

I’ve been reading about Apache Cassandra for the past two weeks. I spent time reading a lot of online blogs and then ended up reading Cassandra: The Definitive Guide. In this post we will discuss what makes Cassandra scalable, why its write path is efficient for suitable workloads, and how it can handle high write throughput.

Before that, we need to understand what Cassandra is and how it differs from other databases.

What Is Apache Cassandra?

Apache Cassandra is a distributed NoSQL database designed for high availability and horizontal scalability. Its architecture is particularly well suited to workloads with predictable query patterns and heavy write traffic.

What makes Cassandra different from relational databases?

  • Horizontally Scalable: Cassandra is designed to scale horizontally by adding nodes to a cluster, with data distributed across the cluster according to the partitioning strategy.
  • Write-Heavy Workloads: Cassandra is designed to handle high write throughput for workloads that fit its data model and access patterns. This is not a statement that relational databases cannot handle heavy writes.
  • Data Model: Cassandra uses CQL and tables, but its data model and query patterns are designed around partition keys and distributed access. It should not be described simply as “schema-less”; table schemas are still defined.
  • No Single Master: Cassandra uses a peer-to-peer architecture rather than a single primary node coordinating every operation. This removes the single-master bottleneck, although availability and failure tolerance still depend on replication and configuration.
  • Data Distribution: In Cassandra data is distributed among all nodes with the help of consistent hashing. This balances data storage in a distributed environment.

Why Is Cassandra Scalable?

Cassandra is designed to run as a distributed cluster of nodes. Three or more nodes are common in production because replication across multiple nodes improves failure tolerance, but Cassandra can also be run with fewer nodes for development or testing. A client can connect to any suitable node, which can act as the coordinator for the request.

A node receiving a request acts as the coordinator. Using the partition key and the cluster’s partitioning strategy, the coordinator determines which replicas are responsible for the data and coordinates the read or write with those replicas.

Of course a lot of stuff happens between these read & write operations, but we will see them later when we discuss speed.

Adding New Nodes to the Cluster

Seed nodes are configured as contact points that help a new Cassandra node discover the cluster. A new node contacts one or more configured seeds to learn enough cluster topology to join the cluster.

What makes Cassandra so much faster?

Log-Structured Storage

Cassandra never updates data “in place.” Instead, all writes are append-only. They go to a commit log and then to an in-memory structure (memtable) and are later flushed to disk as immutable SSTables. Disk writes are sequential, not random, and modern disks, especially SSDs, are much faster with sequential I/O.

Understand it in such a way that Cassandra is a book, and instead of rewriting existing pages, Cassandra adds new pages to the end and regularly cleans up old pages in the background.

No Joins, No Foreign Keys

Cassandra does not provide the same join and foreign-key model as a relational database. Its data model encourages denormalization: you often store data in multiple tables shaped around the queries you need to serve, trading some storage and write complexity for predictable reads.

Distributed Nature

There is no single master in Cassandra, so requests can be coordinated by any node. Work can still be unevenly distributed in practice, depending on partitioning, workload, hotspots, and cluster state.

In-Memory Caching

Cassandra uses Memtable (we will discuss this later in this post), an in-memory data structure that holds data until it is persistently written to disk. Hot data can be directly served from memory, which is very fast as compared to disk reads.

Bloom Filters

If the requested data is not already available through the relevant caches, Cassandra can use Bloom filters to determine whether an SSTable might contain the partition. A negative result can avoid an unnecessary disk read, while a positive result does not prove that the data is present.

Tunable Consistency

Cassandra stores replicas of data on multiple nodes for fault tolerance. The consistency level controls how many replica responses are required before a read or write is considered successful. For example, ONE can acknowledge a write after one replica responds, trading stronger coordination for lower latency.

Important Data Structures & Mechanisms

There are several data structures and mechanisms in Cassandra that make writing and reading data much faster.

Commit Log

The commit log records writes durably before the corresponding in-memory state is flushed to SSTables. It provides a recovery mechanism if a node fails before its memtable is persisted. The exact point at which a write is acknowledged depends on the configured consistency and durability behavior.

Memtable

A memtable is an in-memory structure that holds recent writes. As memtables are flushed, their contents are written to immutable SSTables on disk and a new memtable is used for subsequent writes.

SSTable

SSTable stands for Sorted String Table. It is an immutable on-disk data structure. Updates and deletions are represented through new SSTable data and tombstones rather than modifying an existing SSTable in place.

How data writing works in Cassandra?

  1. Client sends write request to a Cassandra node.
  2. The coordinator uses the partition key and partitioner to determine the replica nodes responsible for the data.
  3. The coordinator sends the write to the replicas.
  4. Replicas append the write to their commit logs and update their memtables.
  5. The coordinator returns success when the configured consistency requirement is satisfied.
  6. Later, memtables are flushed to immutable SSTables.

How data reading works in Cassandra?

  1. Client sends read request.
  2. The coordinator identifies the replica nodes for the partition.
  3. The coordinator requests the data from the appropriate replicas.
  4. The replica can use its caches and SSTable indexes to locate the data.
  5. Bloom filters can rule out SSTables that definitely do not contain the partition.
  6. The required SSTable data is read and the coordinator combines replica responses according to the consistency level.