Cassandra Introduction

In 2008, Facebook had a problem: their inbox search needed to handle 50 billion messages. Each search query had to scan millions of rows across hundreds of servers in milliseconds. Their MySQL cluster was drowning. Two engineers — Avinash Lakshman and Prashant Malik — designed a new database that borrowed ideas from both Amazon's Dynamo paper and Google's Bigtable paper. They called it Cassandra. Facebook open-sourced it in 2008. Apache adopted it in 2010. Today it handles millions of writes per second for Netflix, Instagram, Apple, Twitter, and Uber — and it's about to make complete sense to you.

What Makes Cassandra Fundamentally Different

Cassandra was engineered around one core belief: writes must never block. Every architectural decision flows from this. The result is a database that can ingest a million writes per second across a 10-node cluster — sustained, without degradation.

The Ring Architecture — No Masters, No Hierarchy

Cassandra organises its nodes in a ring. Each node owns a range of the token space (0 to 2^64). When you write a row, Cassandra hashes the partition key to a token, finds which node owns that token range, and writes there. Every node knows the ring topology — any node can route any request.

CQL — Cassandra Query Language

CQL looks like SQL — familiar syntax, familiar keywords. But it behaves completely differently under the hood. The most important difference: CQL only allows queries that use the partition key. Anything else requires an index or a full table scan — which Cassandra was not designed for.

Table Design — The Most Critical Cassandra Skill

In Cassandra, your table design is your query. You design tables around the queries you need to run — not around the data's natural relationships. This is the opposite of relational design.

The scenario: You're building a ride-hailing platform. Drivers send GPS coordinates every 5 seconds. You need two query patterns: (1) get all locations for a specific driver in the last hour, (2) get the most recent location for a driver. Here's how to design for both:

-- Connect to Cassandra
cqlsh

-- Create a keyspace (equivalent to a database)
CREATE KEYSPACE ridehailing
  WITH replication = {
    'class': 'NetworkTopologyStrategy',
    'us-east': 3    -- 3 replicas in us-east datacenter
  };

USE ridehailing;

-- Design the table around the query: "all locations for driver X in last hour"
CREATE TABLE driver_locations (
  driver_id   TEXT,       -- partition key: all rows for one driver on one node
  recorded_at TIMESTAMP,  -- clustering column: rows sorted by time within partition
  latitude    DOUBLE,
  longitude   DOUBLE,
  speed_kmh   FLOAT,
  PRIMARY KEY (driver_id, recorded_at)
) WITH CLUSTERING ORDER BY (recorded_at DESC);
-- DESC = most recent first — "latest location" query reads the first row only

Writing Data — The Fast Path

The scenario: 80,000 drivers sending GPS pings every 5 seconds — that's 16,000 writes per second. Here's how Cassandra handles them:

from cassandra.cluster import Cluster
from cassandra import ConsistencyLevel
from cassandra.query import SimpleStatement
from datetime import datetime

cluster = Cluster(['node1', 'node2', 'node3'])
session = cluster.connect('ridehailing')

# Prepare the statement once — reuse for every write
# Prepared statements are compiled once and sent by ID on reuse — faster
insert_location = session.prepare("""
  INSERT INTO driver_locations (driver_id, recorded_at, latitude, longitude, speed_kmh)
  VALUES (?, ?, ?, ?, ?)
  USING TTL 86400
""")
# TTL 86400 = auto-delete after 24 hours (location data is temporary)

# Execute a write with QUORUM consistency
# QUORUM = majority of replicas must confirm (2 out of 3 with RF=3)
bound = insert_location.bind((
    'driver_d7821',
    datetime.now(),
    51.5074,       # latitude
    -0.1278,       # longitude
    42.5           # speed in km/h
))
bound.consistency_level = ConsistencyLevel.QUORUM

session.execute(bound)

-- Write path internally:
-- 1. Driver receives write request
-- 2. Hashes 'driver_d7821' to token → finds primary node
-- 3. Writes to primary node's commit log (disk) — for durability
-- 4. Writes to primary node's memtable (RAM) — for fast reads
-- 5. Forwards to RF-1 replica nodes asynchronously
-- 6. QUORUM: waits for 2/3 nodes to confirm → returns OK

Write acknowledged: ~1.8ms
No locking. No transaction log coordination across nodes.

Reading Data — Partition Key First, Always

The scenario: Fetch the last hour of GPS data for a driver, and separately fetch just the most recent location:

from datetime import datetime, timedelta

one_hour_ago = datetime.now() - timedelta(hours=1)

# Query 1: last hour of locations for driver_d7821
rows = session.execute("""
  SELECT recorded_at, latitude, longitude, speed_kmh
  FROM driver_locations
  WHERE driver_id   = 'driver_d7821'
    AND recorded_at >= %s
""", (one_hour_ago,))

for row in rows:
    print(f"{row.recorded_at}: ({row.latitude}, {row.longitude}) @ {row.speed_kmh}km/h")

2024-01-15 15:59:55: (51.5074, -0.1278) @ 42.5km/h
2024-01-15 15:59:50: (51.5071, -0.1275) @ 41.2km/h
2024-01-15 15:59:45: (51.5068, -0.1272) @ 40.8km/h
...720 rows (one per 5 seconds for 1 hour)

Query time: 6ms
Rows scanned: 720 (sequential read of one partition — no cross-node lookups)

# Query 2: most recent location only — LIMIT 1 on DESC-ordered partition
row = session.execute("""
  SELECT recorded_at, latitude, longitude
  FROM driver_locations
  WHERE driver_id = 'driver_d7821'
  LIMIT 1
""").one()

print(f"Last seen: {row.recorded_at} at ({row.latitude}, {row.longitude})")

Last seen: 2024-01-15 15:59:55 at (51.5074, -0.1278)

Query time: 0.9ms
Rows scanned: 1 (reads first row of partition — already sorted DESC)

Consistency Levels — The Tunable Dial

Cassandra's consistency level is set per-query — not per-table or per-database. This is unique: you can run the same table with strong consistency for critical reads and eventual consistency for bulk analytics, all in the same application.

The Partition Key Problem — Hot Partitions

The most common Cassandra mistake is a poor partition key. If your partition key has low cardinality — few unique values — all the traffic goes to a small number of nodes. This is called a hot partition and it destroys performance.

Practice Questions — You're the Engineer

Quiz — Cassandra Under Pressure