Wide-column stores like Cassandra

NoSQL and choosing a database Senior Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Pick the fix

A chat app stores messages with partition key conversation_id only, and old busy conversations get slow. Fix?

Options
Hint 1 of 1

What grows without limit?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Partition by (conversation_id, month) to bound partition size

Correct. Each partition stays a manageable size.

In Cassandra-style stores a partition key's rows all live together, so a busy conversation grows one huge partition. Adding a time bucket like the month caps how big each partition gets.

Why not the others?
  • B Add a secondary index on timestamp. Doesn't shrink the partition.
  • C Raise the consistency level. Makes reads slower, not smaller.
  • D Delete old messages daily. Tombstones add their own read cost.

30-second answer

Cassandra is a leaderless, wide-column store built for high write throughput across data centers with tunable consistency. You model one table per query: the partition key decides which nodes hold the data, clustering columns order rows within a partition, and you denormalize freely because there are no joins. It's strong for time series, event logs and messaging inboxes; weak for ad hoc queries and multi-row transactions.

Practise saying it · 30 s. No recording, just a timer

When use Cassandra?

Say your answer out loud, then check which of these points you covered:

  • Leaderless, write-heavy, multi-DC
  • Table per query
  • Bounded partitions
  • Tombstones
  • Tunable consistency

Deep dive

Consistency levels per query: QUORUM reads + QUORUM writes overlap.

Deletes write tombstones; heavy delete patterns slow reads until compaction.

Keep partitions bounded (for example by adding a time bucket).

Lightweight transactions (IF NOT EXISTS) use Paxos and are much slower.

Common mistakes

  • Unbounded partitions (all events for a user forever).
  • Using it as a queue with constant deletes.
  • Expecting secondary indexes to work like PostgreSQL's.

Senior take & follow-ups

Write-heavy, multi-DC, query-first modelling, and the tombstone and partition-size pitfalls.

Follow-up questions

Think of your answer first, then open the hint.

  1. Why time buckets in keys?

    Show hint

    To keep partitions from growing without limit.

  2. What's a tombstone?

    Show hint

    A deletion marker that reads must skip until compaction removes it.

Related questions

Suggest a fix if something here is wrong or out of date.