Cassandra Performance Tuning Interview Questions
Master Apache Cassandra Performance Tuning with interview questions covering JVM tuning, Garbage Collection, Memtables, SSTables, Compaction, Compression, Bloom Filters, Caches, Tombstones, Monitoring, Capacity Planning, and production best practices.
Introduction
Apache Cassandra is designed to handle millions of writes per second, but achieving that performance requires proper tuning.
Most production performance issues are caused by
- Poor Data Modeling
- Large Partitions
- Incorrect JVM Settings
- Tombstones
- Improper Compaction
- Poor Hardware Configuration
- Missing Monitoring
Understanding Cassandra tuning is one of the most common topics in senior Backend, Database Engineer, Platform Engineer, and Solution Architect interviews.
Cassandra Performance Architecture
flowchart LR
Client --> Coordinator --> CommitLog --> Memtable --> SSTables --> Cache --> Application
1. What affects Cassandra performance?
Answer
Major factors include
- Data Model
- Partition Key
- Compaction
- JVM
- Memory
- Disk
- CPU
- Network
- Replication
- Consistency Level
2. What is the most important performance optimization?
Good Data Modeling.
A poor partition key cannot be fixed by hardware upgrades.
3. Why is Partition Size important?
Large partitions cause
- Slow Reads
- Long Compactions
- High GC
- Repair Delays
Recommended
Keep partitions below 100 MB whenever practical.
4. How do you identify Large Partitions?
Command
nodetool tablestats
Monitor
- Largest Partition
- SSTable Count
- Read Latency
5. What is JVM Tuning?
Cassandra runs on the JVM.
Proper JVM tuning improves
- Throughput
- Latency
- Garbage Collection
- Stability
JVM Architecture
flowchart LR
Application --> Heap --> GarbageCollector --> CPU
6. Recommended Heap Size?
General Recommendation
8 GB
to
16 GB
Avoid extremely large heap sizes because they increase GC pause times.
7. Which Garbage Collector is commonly used?
Modern Cassandra versions commonly use
- G1GC
Benefits
- Predictable Pause Times
- Better Large Heap Performance
8. How do you reduce Garbage Collection pauses?
- Smaller Heap
- Better Data Model
- Fewer Tombstones
- Avoid Large Objects
- Tune Memtables
9. What is Memtable?
Memtable is an in-memory write buffer.
Writes
↓
Commit Log
↓
Memtable
↓
SSTable
10. How do Memtables affect performance?
Larger Memtables
Advantages
- Fewer Flushes
Disadvantages
- More Memory Usage
- Longer Recovery
11. What is SSTable?
Immutable on-disk storage file.
Benefits
- Sequential Writes
- Fast Reads
- Lock-Free Storage
12. Why are too many SSTables bad?
Problems
- More Disk Reads
- Higher Read Latency
- More Bloom Filter Checks
Solution
Proper Compaction.
13. What is Compaction?
Compaction merges SSTables.
Benefits
- Remove Tombstones
- Merge Updates
- Improve Reads
Compaction Flow
flowchart LR
SSTable1 --> Compaction
SSTable2 --> Compaction
SSTable3 --> Compaction
Compaction --> OptimizedSSTable
14. Compaction Strategies
SizeTieredCompactionStrategy (STCS)
Best for
- Write-heavy workloads
LeveledCompactionStrategy (LCS)
Best for
- Read-heavy workloads
TimeWindowCompactionStrategy (TWCS)
Best for
- Time-Series Data
- Logs
- IoT
- Metrics
15. Which Compaction Strategy should be used?
| Workload | Strategy |
|---|---|
| Write Heavy | STCS |
| Read Heavy | LCS |
| Time Series | TWCS |
16. What is Compression?
Compresses SSTables.
Benefits
- Lower Storage
- Faster Reads
- Reduced IO
Popular
LZ4 Compression
17. What is Bloom Filter?
Bloom Filter determines whether data
may exist
inside an SSTable.
Benefits
- Avoid Unnecessary Disk Reads
- Improve Read Performance
Bloom Filter
flowchart LR
ReadRequest --> BloomFilter --> PossibleMatch --> DiskRead
18. What caches does Cassandra provide?
- Key Cache
- Row Cache
19. Difference between Key Cache and Row Cache?
| Key Cache | Row Cache |
|---|---|
| Stores Partition Locations | Stores Actual Rows |
| Lower Memory | Higher Memory |
| Recommended | Limited Usage |
20. Should Row Cache always be enabled?
No.
Suitable only for
- Frequently Accessed Static Data
21. What are Tombstones?
Deletes create Tombstones.
Problems
- Slower Reads
- Longer Compaction
- More Disk Usage
22. How do Tombstones affect performance?
Large numbers of Tombstones
↓
More SSTables
↓
Longer Reads
↓
Higher Latency
23. How do you reduce Tombstones?
- Avoid Frequent Deletes
- Avoid Short TTL
- Schedule Compaction
- Design Better Data Model
24. What is Read Latency?
Time required to return data.
Affected by
- SSTables
- Compaction
- Cache
- Disk IO
25. What is Write Latency?
Time required to store data.
Affected by
- Commit Log
- Memtable
- Consistency Level
- Disk Speed
26. Which hardware is best for Cassandra?
Recommended
- SSD
- High Memory
- Multi-Core CPU
- Fast Network
Avoid
Slow HDDs.
27. How important is SSD?
Very important.
Benefits
- Lower Latency
- Faster Compaction
- Faster Reads
- Faster Repairs
28. What monitoring metrics should be tracked?
- CPU
- Memory
- Disk
- Read Latency
- Write Latency
- Pending Compactions
- Heap Usage
- GC Time
- Tombstones
- SSTables
Monitoring Architecture
flowchart LR
Cassandra --> JMX --> Prometheus --> Grafana
29. Useful Monitoring Commands
nodetool status
nodetool info
nodetool tpstats
nodetool tablestats
nodetool compactionstats
nodetool cfstats
30. What is Capacity Planning?
Forecast future resource requirements.
Monitor
- Storage Growth
- Read Throughput
- Write Throughput
- Node Utilization
31. How do you scale Cassandra?
Simply add new nodes.
Benefits
- Linear Scalability
- Automatic Rebalancing
- Higher Throughput
Scaling Architecture
flowchart LR
Cluster --> Node1
Cluster --> Node2
Cluster --> Node3
Cluster --> NewNode
32. Common Performance Problems
- Large Partitions
- Hot Partitions
- Too Many SSTables
- Excessive Tombstones
- Frequent Repairs
- Bad Compaction Strategy
- Slow Storage
- High GC
33. Real Banking Example
Problem
Transaction history queries became slow.
Investigation
- Large Monthly Partition
- 12 Million Rows
- High Read Latency
Solution
Partition changed from
PRIMARY KEY
((account_id),
transaction_time)
to
PRIMARY KEY
((account_id,month),
transaction_time)
Result
- Smaller Partitions
- Faster Reads
- Better Compaction
- Reduced Latency
34. Real IoT Example
Problem
Sensor table reached
500 GB
single partition.
Solution
Bucket by
device_id
+
day
Result
- Balanced Cluster
- Faster Queries
- Lower Repair Time
Enterprise Best Practices
- Design tables around query patterns.
- Keep partition sizes below 100 MB whenever practical.
- Use SSD storage.
- Use RF = 3.
- Choose the correct compaction strategy.
- Schedule regular repair operations.
- Monitor tombstone growth.
- Keep JVM heap between 8–16 GB in most deployments.
- Monitor read/write latency continuously.
- Use Prometheus and Grafana dashboards.
- Avoid unnecessary secondary indexes.
- Test production workloads before release.
Quick Revision
| Component | Best Practice |
|---|---|
| Partition Size | < 100 MB |
| Heap Size | 8–16 GB |
| Storage | SSD |
| Replication Factor | 3 |
| GC | G1GC |
| Write Buffer | Memtable |
| Storage | SSTable |
| Read Optimization | Bloom Filter |
| Read Cache | Key Cache |
| Write Heavy | STCS |
| Read Heavy | LCS |
| Time Series | TWCS |
| Monitoring | Prometheus + Grafana |
Interview Tips
Interviewers frequently ask
- How do you tune Cassandra?
- Which compaction strategy would you choose?
- Why are large partitions bad?
- Explain Bloom Filters.
- Explain Memtables and SSTables.
- What causes high read latency?
- How do Tombstones affect performance?
- Why are SSDs recommended?
- Which JVM GC should Cassandra use?
- How do you troubleshoot a slow Cassandra cluster?
Always explain how you would investigate the issue first, using metrics, logs, and nodetool commands before suggesting configuration changes.
Summary
Cassandra performance tuning begins with a well-designed data model and extends to JVM optimization, storage configuration, compaction strategy, caching, monitoring, and capacity planning. Components such as Memtables, SSTables, Bloom Filters, Compaction, Compression, and G1 Garbage Collection work together to deliver high throughput and low latency.
Mastering partition sizing, tombstone management, compaction strategies, JVM tuning, monitoring, and production troubleshooting is essential for designing enterprise-scale Cassandra deployments and succeeding in senior backend, database engineering, platform engineering, and solution architect interviews.