Tiffin's riders send their location every 4 seconds. With 150,000 riders on shift at the dinner peak across 40 cities, that's 37,500 writes a second at peak and about a billion rows a day, every day, and the operations team wants 90 days of history to settle disputes ("the rider never came to my building"). That's about 90 billion rows. A single Postgres primary can't take that write rate forever, and sharding it by hand (Module 9) is a project of its own.
Apache Cassandra is built for this shape of problem: huge volumes of writes, data spread across many machines, no single point of failure, and queries you know in advance. This lesson recaps the ideas it borrows (leaderless replication from Module 13, consistent hashing from Module 14, LSM trees from Module 19) and shows how they fit together.
What it's best at
- Write-heavy workloads at scale: events, time series, logs, messages, sensor readings.
- Always-on systems: no leader to fail over, so a node or even a whole data centre can drop out without downtime.
- Multi-region: each region accepts writes locally.
- Predictable queries: "the last 100 events for X", "everything for X between two times".
Apple, Netflix and Discord (for years) ran it at very large scale. Discord later moved to ScyllaDB, a C++ reimplementation with the same data model.