What are common Cassandra anti-patterns to avoid?
Learn the top Cassandra anti-patterns — unbounded partitions, hotspots, ALLOW FILTERING and tombstones — and how query-first modeling keeps reads fast at scale.
Expected Interview Answer
Common Cassandra anti-patterns include unbounded partitions, low-cardinality partition keys that create hotspots, using Cassandra like a relational database with joins and ad-hoc queries, heavy use of secondary indexes, and abusing tombstones through frequent deletes or updates to collections.
Cassandra rewards query-first data modeling: you design tables around the exact reads you need, denormalizing and duplicating data across tables rather than joining at read time. Anti-patterns almost always stem from imposing relational habits — normalizing, filtering with ALLOW FILTERING, relying on secondary indexes, or letting a single partition grow without bound — which defeat Cassandra's distributed, partition-based architecture and cause hotspots, latency spikes, and read amplification from tombstones.
- Avoids partition hotspots and uneven cluster load
- Keeps read latency low and predictable
- Prevents tombstone-driven read amplification
- Scales linearly as nodes are added
- Eliminates expensive cluster-wide scatter-gather queries
AI Mentor Explanation
Picking a low-cardinality partition key is like assigning every player in a tournament to the same dressing room because you only sorted them by 'is a cricketer'. One room overflows while others sit empty, and the twelfth man can never find anyone. A good key is like assigning rooms by squad number, spreading players evenly so each room stays manageable and searchable.
Step-by-Step Explanation
Step 1
Model queries first
List the exact read patterns your app needs, then design one table per query rather than normalizing entities.
Step 2
Choose high-cardinality keys
Pick partition keys that spread data evenly and avoid columns with few distinct values that concentrate load.
Step 3
Bound your partitions
Add a time or hash bucket to the partition key so a single partition never grows without limit.
Step 4
Avoid ALLOW FILTERING and secondary indexes
Duplicate data into a purpose-built table keyed by the lookup column instead of scanning or indexing at read time.
Step 5
Minimize tombstones
Design to avoid frequent deletes, collection updates, and inserting nulls; tune gc_grace and compaction to reclaim them.
What Interviewer Expects
- Understanding that Cassandra is query-first, not entity-first
- Awareness of partition sizing and hotspot risks
- Knowledge of why ALLOW FILTERING is dangerous at scale
- Explanation of tombstones and their read-time cost
- Recognition that denormalization and duplication are intentional
Common Mistakes
- Normalizing data and expecting joins to work
- Using ALLOW FILTERING in production queries
- Choosing a low-cardinality partition key that creates hotspots
- Letting partitions grow unbounded without bucketing
- Ignoring tombstone buildup from frequent deletes or null inserts
Best Answer (HR Friendly)
“Cassandra works best when you design your tables around the specific questions you'll ask, not around neat entity relationships. The big mistakes are treating it like a traditional SQL database, letting any single storage bucket grow too large, and doing lots of deletes, all of which slow it down.”
Code Example
-- Anti-pattern: unbounded partition, all events under one sensor
CREATE TABLE events_bad (
sensor_id text,
ts timestamp,
reading double,
PRIMARY KEY (sensor_id, ts)
);
-- Better: bucket by month so partitions stay bounded
CREATE TABLE events_good (
sensor_id text,
month text, -- e.g. '2026-07'
ts timestamp,
reading double,
PRIMARY KEY ((sensor_id, month), ts)
);Follow-up Questions
- Why is ALLOW FILTERING considered dangerous in production?
- How do tombstones affect read performance and how do you control them?
- What makes a good partition key in Cassandra?
- How do you bound a partition that would otherwise grow forever?
- When are secondary indexes acceptable in Cassandra?
MCQ Practice
1. Which is a Cassandra data-modeling anti-pattern?
Low-cardinality partition keys concentrate data and traffic on few partitions, creating hotspots and uneven cluster load.
2. Why is ALLOW FILTERING discouraged?
ALLOW FILTERING lets Cassandra scan and filter across partitions, which does not scale and causes unpredictable latency.
3. What problem do excessive tombstones cause?
Readers must scan past tombstones until compaction removes them, amplifying read cost on delete-heavy tables.
Flash Cards
What is a partition hotspot? — Uneven load where a low-cardinality key sends most traffic to a few partitions instead of spreading it.
Why avoid ALLOW FILTERING? — It triggers scatter-gather scans across partitions that do not scale and cause latency spikes.
What is a tombstone? — A marker for a deleted or null value that readers scan past until compaction reclaims it.
How do you bound a partition? — Add a time or hash bucket to the partition key so no single partition grows unbounded.