Apache Cassandra is an open-source, distributed NoSQL database management system designed for handling large amounts of data across many commodity servers without a single point of failure. Originally developed at Facebook and released as open source in 2008, Cassandra is now maintained by the Apache Software Foundation and is one of the most widely deployed NoSQL databases in the world. Organizations including Apple, Netflix, Instagram, Twitter, and Spotify use Cassandra to power high-volume, always-available data workloads.
Cassandra is classified as a wide-column store — a NoSQL database type that organizes data into tables with rows and dynamic columns, but unlike relational databases, Cassandra's columns can vary per row and are not constrained by a fixed schema to the same degree. This architecture makes Cassandra exceptionally well-suited for time-series data, event logging, user activity tracking, and other workloads where data is append-heavy and queries access data by known partition keys rather than performing ad-hoc joins across tables.
Cassandra's defining characteristics are: linear horizontal scalability (adding nodes increases capacity and throughput proportionally), masterless peer-to-peer architecture (no single point of failure, every node is equal), tunable consistency (allowing developers to choose the trade-off between consistency and availability per operation), high write throughput optimized through a log-structured merge-tree (LSM tree) storage model, and geographic distribution support through multi-datacenter replication. These characteristics make Cassandra a natural fit for globally distributed applications that cannot tolerate downtime.
Understanding Cassandra's architecture is essential for data modeling correctly — Cassandra's design philosophy strongly dictates how data should be organized, and models that work well in relational databases often perform poorly in Cassandra.
Cassandra organizes nodes in a cluster into a logical ring. Each node is responsible for a range of data determined by its position on the ring. When data is written, a hash function (called a partitioner) generates a token from the partition key, and that token determines which node (or nodes, with replication) stores the data. The default partitioner (Murmur3Partitioner) distributes data uniformly across nodes. This ring architecture means there is no single master node — any node can accept any read or write request, and the receiving node coordinates the operation with the appropriate replica nodes.
Cassandra's data hierarchy: a cluster contains keyspaces (analogous to databases in relational systems), which contain tables (analogous to tables, but with critical differences). Keyspaces define the replication strategy and replication factor for all tables they contain. Tables in Cassandra are defined by a primary key consisting of a partition key (which determines data distribution) and optionally clustering columns (which determine sort order within a partition). All rows with the same partition key value are stored together on the same node(s) — this co-location is what makes Cassandra queries fast.
The most important principle in Cassandra data modeling is: design tables around your queries, not around your data. In relational databases, you normalize data and write flexible queries. In Cassandra, you denormalize — you duplicate data across multiple tables optimized for specific query patterns. Before creating a table, you must know which partition key will be used in every query against that table. Queries that cannot filter by partition key require full-cluster scans (called ALLOW FILTERING), which are extremely slow and should almost never be used in production.
Cassandra Query Language (CQL) is Cassandra's query interface, designed to look familiar to SQL users while reflecting Cassandra's distributed data model. While CQL looks superficially similar to SQL, critical differences reflect Cassandra's design constraints — particularly around which query patterns are supported efficiently.
CQL supports standard DDL and DML operations: CREATE KEYSPACE, CREATE TABLE, INSERT, UPDATE, DELETE, and SELECT. Creating a table requires specifying the primary key, which consists of the partition key and optionally clustering columns:
CREATE TABLE user_events (user_id UUID, event_time TIMESTAMP, event_type TEXT, details TEXT, PRIMARY KEY (user_id, event_time)) WITH CLUSTERING ORDER BY (event_time DESC);
This table uses user_id as the partition key (all events for a user stored together) and event_time as a clustering column (sorted newest first within each partition). Queries must include the partition key: SELECT * FROM user_events WHERE user_id = ? — this efficiently retrieves all events for a user. Without the partition key filter, Cassandra would need to scan all partitions across the entire cluster.
Key differences from SQL that Cassandra developers must understand: no joins (Cassandra has no JOIN operation — data must be denormalized); no subqueries; WHERE clauses must include the partition key or use ALLOW FILTERING (avoid in production); ORDER BY only applies to clustering columns within a partition (not arbitrary columns); aggregations (COUNT, SUM, AVG) work only within a single partition; no foreign keys or referential integrity constraints. CQL supports batch statements (multiple writes executed atomically on a single partition), lightweight transactions (compare-and-set operations via IF conditions), and time-to-live (TTL) for automatic data expiration.
CQL supports a rich set of data types including: primitive types (TEXT, VARCHAR, INT, BIGINT, FLOAT, DOUBLE, BOOLEAN, TIMESTAMP, UUID, TIMEUUID, BLOB), collection types (LIST, SET, MAP — for multi-value fields within a single column), and frozen types (collections embedded as a single value in another collection or user-defined type). The TIMEUUID type — a UUID that incorporates a timestamp — is particularly useful for time-ordered data, allowing unique, sortable identifiers without timestamp collisions.
Cassandra's scalability and fault tolerance derive from its partitioning and replication mechanisms. Understanding these is critical for both database design and operations.
The partition key determines which node(s) store each row. Cassandra's partitioner (typically Murmur3Partitioner) hashes the partition key to generate a token — a large integer that maps to a position on the ring. The node responsible for that token range stores the data. Good partition keys distribute data uniformly across nodes. Bad partition keys — such as using a date or status field that concentrates many rows under a single value — create 'hot partitions' that overload specific nodes while others sit idle. A Cassandra anti-pattern to avoid: choosing a partition key with low cardinality (few distinct values) that results in very large partitions. Cassandra partitions should generally stay under 100MB in size.
Cassandra replicates data across multiple nodes for fault tolerance. The replication factor (RF) specifies how many copies of each partition exist across the cluster. An RF of 3 — the most common production configuration — means each partition is stored on 3 different nodes. With RF=3, the cluster can lose any 1 node (or even 2 nodes in some configurations) without data loss or availability interruption. Replication strategies: SimpleStrategy (replicates to the next N nodes clockwise on the ring — not recommended for production); NetworkTopologyStrategy (replicates within and across datacenters according to a specified strategy — recommended for any production deployment).
Cassandra's tunable consistency allows you to choose how many replicas must acknowledge a read or write before the operation is considered successful. Common consistency levels: ONE (fastest, least consistent — only one replica responds), QUORUM (majority of replicas must respond — strong consistency when RF=3: 2 of 3 must respond), ALL (all replicas must respond — strongest consistency, lowest availability), LOCAL_QUORUM (quorum within the local datacenter — useful in multi-DC deployments), and LOCAL_ONE (single replica in local DC — fast, but potentially stale). The formula for strong consistency: write CL + read CL > RF. With RF=3, writing at QUORUM and reading at QUORUM (2+2=4 > 3) guarantees you will read your writes.
Cassandra is optimized for high write throughput and fast partition-key reads. Understanding the storage model and common operational concerns helps you get the best performance from Cassandra deployments.
Cassandra uses a Log-Structured Merge-Tree (LSM tree) storage model that makes all writes sequential and very fast. Writes first go to a commit log (for durability) and an in-memory structure called a MemTable. When the MemTable fills, it is flushed to disk as an immutable SSTable (Sorted String Table) file. Over time, multiple SSTables accumulate; Cassandra periodically merges them through a process called compaction, which removes deleted data (marked with tombstones) and improves read performance by reducing the number of SSTables that must be consulted per read.
Deletion in Cassandra does not immediately remove data — instead, it writes a tombstone marker. The tombstone tells Cassandra and its replicas that the data has been deleted. Tombstones accumulate until compaction removes them. A common Cassandra performance issue: queries that encounter many tombstones (because data was frequently deleted) become slow because Cassandra must scan and skip tombstones to find live data. The gc_grace_seconds setting (default 10 days) controls how long tombstones persist before being eligible for garbage collection — never set this to 0 without understanding the implications.
Key Cassandra metrics to monitor: read and write latency (p99 and p999 percentiles), pending compaction tasks (backlog indicates the compaction system is falling behind), dropped mutations (writes that were not applied within the timeout window), heap memory usage (JVM heap — Cassandra is a Java application), and partition size. Tools for Cassandra operations: nodetool (the primary CLI for cluster management, ring status, compaction management), Apache Cassandra's built-in metrics exposed via JMX (monitored through Prometheus, Grafana, or DataStax OpsCenter), and DataStax Astra (the managed Cassandra cloud service) for simplified operations.
Prepare for the CASSANDRA - Apache Cassandra Database exam with our free practice test modules. Each quiz covers key topics to help you pass on your first try.