Stop 07 · NoSQL DatabasesTopics · 11/12

Cassandra (Overview)

Part of the Backend Developer Roadmap

In short

When an app writes huge amounts of data across many machines and can't afford downtime, teams often reach for Apache Cassandra. Here's how it thinks.

A wide-column NoSQL database built for massive write throughput and multi-datacenter replication — used by companies operating at extreme scale (originally built at Facebook).

The blob stands inside a circle of ticket booths that pass copies to their neighbours.

Think of it like this

A ring of ticket counters

Picture a station with booths in a circle. Your ticket's number decides which booth stores it, and neighbours keep copies. If one booth shuts for lunch, a neighbour still has your ticket. There's no head booth that can fail. That's Cassandra's ring.

Watch it happen

One write, many copies

App
Node A
Node B
Node C

INSERT (sensor 9)

1/6The app can send a write to any node. Node A becomes the coordinator for it.

The big ideas

What you need to know

No leader

Every node is equal and any node can take reads and writes, so there's no single point of failure.

Partition key decides placement

The partition key is hashed to pick which nodes store a row. Queries usually must include it.

Tunable consistency

Choose per query how many replicas must answer: ONE for speed, QUORUM for safety.

One table per query

No joins and limited filtering. You often create a table for each query, duplicating data on purpose.

See it in code

Walk through the code

sql
1CREATE TABLE readings_by_sensor (2  sensor_id  int,3  day        date,4  ts         timestamp,5  temp       float,6  PRIMARY KEY ((sensor_id, day), ts)7) WITH CLUSTERING ORDER BY (ts DESC);8 9-- Fast: includes the full partition key10SELECT ts, temp FROM readings_by_sensor11WHERE sensor_id = 9 AND day = '2026-10-27' LIMIT 100;

1/3(sensor_id, day) is the partition key: one sensor's day of readings lives together.

This is CQL, Cassandra's SQL-like language. It looks familiar, but there are no joins and WHERE must follow the key design.

Save yourself the pain

Common mistakes

Oops

Querying by a column that isn't part of the primary key.

Do this instead

Cassandra rejects it or needs ALLOW FILTERING, which scans. Create another table shaped for that query.

Oops

Picking Cassandra for a small app full of relations.

Do this instead

It shines with heavy writes across many nodes. For a few lakh rows with joins, Postgres is far simpler.

Your mission

Try Cassandra locally

~30 min

Quick check

In Cassandra, why must most queries include the partition key?

Go deeper

  1. 1Read a high-level overview of Cassandra's architecture — no master node, eventual consistency.
  2. 2Understand its trade-off: extreme write scalability in exchange for weaker consistency guarantees.
  3. 3Recognize this is a specialized tool — most projects will never need it.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge