40 Cassandra Interview Questions and Answers

Cassandra is a highly scalable, distributed NoSQL database designed to handle large amounts of data across many commodity servers. It is used for applications that require high availability, fault tolerance, and scalability, such as real-time big data analytics, IoT, and recommendation engines.

Cassandra uses a peer-to-peer distributed architecture where data is replicated across multiple nodes. If one node fails, others can continue serving requests, ensuring no single point of failure and continuous availability.

Eventual consistency means that updates to the database will propagate to all nodes over time, so all replicas will eventually have the same data. This allows Cassandra to provide high availability and partition tolerance, even if some nodes are temporarily unreachable.

A keyspace in Cassandra is similar to a schema in relational databases. It defines the logical grouping of tables, along with settings like replication strategy and replication factor.

In Cassandra, data modeling is query-driven and denormalized. Instead of designing normalized tables with foreign keys, you design tables based on the queries you need to support, often duplicating data to optimize for fast reads.

A partition key determines how data is distributed across the nodes in a Cassandra cluster. It ensures even data distribution and efficient query performance by grouping related rows together on the same node.

Cassandra writes data to a commit log for durability, then stores it in memory (memtable) before flushing it to disk (SSTable). Reads first check the memtable and cache, then the SSTables, merging results as needed.

A replica is a copy of data stored on a different node. Cassandra replicates data based on the replication factor defined in the keyspace, distributing replicas across nodes to ensure fault tolerance and data availability.

Cassandra allows you to configure the consistency level for each read or write operation, balancing between consistency, availability, and performance. For example, you can require a response from one, some, or all replicas.

Cassandra offers features like linear scalability, decentralized architecture, tunable consistency, support for multi-data center replication, and high write throughput, making it suitable for mission-critical applications.

In Cassandra, the primary key uniquely identifies a row and consists of one or more columns. The first part is the partition key, which determines the node where the data is stored. The remaining columns are clustering keys, which define the order of data within the partition. This structure enables efficient querying and sorting within partitions.

Cassandra supports dynamic schema changes. You can add or remove columns from tables without downtime. Schema changes are propagated across the cluster using the gossip protocol, ensuring all nodes are aware of the new schema.

Compaction is the process of merging multiple SSTables into a single SSTable, removing deleted data and consolidating updates. This improves read performance and reclaims disk space. Cassandra supports different compaction strategies, such as SizeTiered and Leveled Compaction, to optimize for various workloads.

A tombstone is a marker created when data is deleted in Cassandra. Instead of immediately removing the data, Cassandra marks it with a tombstone, which is later purged during compaction. Excessive tombstones can degrade read performance and increase disk usage until compaction occurs.

Cassandra uses mechanisms like hinted handoff, read repair, and anti-entropy repair (using the nodetool repair command) to synchronize data across nodes. These processes ensure that eventually all replicas converge to the same state, maintaining data consistency.

The gossip protocol is a peer-to-peer communication mechanism used by Cassandra nodes to exchange information about cluster state, node health, and schema changes. It enables decentralized coordination and helps nodes detect failures quickly.

When a client sends a request, any node can act as the coordinator. The coordinator node determines which nodes own the requested data, forwards the request to the appropriate replicas, collects responses, and returns the result to the client. It also enforces the requested consistency level.

Cassandra is well-suited for time-series data due to its write-optimized architecture. Best practices include designing partition keys to avoid hotspots, using bucketing strategies (e.g., by day or hour), and limiting partition size to ensure efficient reads and writes.

Secondary indexes in Cassandra allow querying by columns other than the primary key. However, they can impact performance and are best used for low-cardinality columns or when queries are not frequent. For high-performance needs, it’s better to design tables around query patterns.

The replication factor determines how many copies of each piece of data are stored across the cluster. A higher replication factor increases data durability and availability, as more nodes can serve requests and recover from failures. However, it also increases storage requirements.

QUORUM requires a majority of replicas in the local data center to acknowledge a read or write, ensuring strong consistency within that data center. EACH_QUORUM requires a quorum of replicas in each data center for multi-data center deployments, providing stronger cross-DC consistency. Use QUORUM for single-DC or local consistency, and EACH_QUORUM for global consistency across multiple data centers.

The partitioner determines how data is distributed across nodes by hashing the partition key. Changing the partitioner after data is loaded requires a full data migration, as all data must be redistributed according to the new hash function. This can be disruptive and is generally not recommended for production clusters.

SizeTieredCompactionStrategy (STCS) merges SSTables of similar sizes, optimizing for write-heavy workloads. LeveledCompactionStrategy (LCS) organizes SSTables into levels with non-overlapping key ranges, optimizing for read-heavy workloads and low-latency queries. Use STCS for write-intensive applications and LCS for read-intensive or time-series workloads.

Hinted handoff temporarily stores hints about missed writes for unavailable nodes. When the node recovers, the coordinator forwards the missed writes. While this helps maintain availability, it does not guarantee consistency if the node is down for an extended period or if hints are lost due to coordinator failure or TTL expiration.

Anti-entropy repair synchronizes data between replicas by comparing Merkle trees and streaming missing or inconsistent data. It is critical for maintaining consistency, especially after node failures or network partitions, and should be run regularly to prevent data divergence.

Materialized views automatically maintain a denormalized, query-optimized copy of base table data. They simplify query patterns but can introduce write amplification, increased storage usage, and eventual consistency issues. Materialized views are best used for simple, low-volume use cases.

Large partitions can cause performance degradation, increased GC pressure, and slow reads/writes. Cassandra recommends keeping partition sizes below 100MB and using bucketing strategies to avoid hotspots and ensure even data distribution.

Commit log archiving involves storing commit logs externally (e.g., on cloud storage) to enable point-in-time recovery after catastrophic failures. By replaying archived commit logs, you can restore data lost since the last snapshot, improving disaster recovery capabilities.

Cassandra writes data to the commit log before updating the memtable. If a node crashes before flushing to SSTables, the commit log is replayed on restart to recover lost writes, ensuring durability.

The snitch informs Cassandra about network topology, data center, and rack placement. Proper snitch configuration ensures replicas are distributed across failure domains, optimizing fault tolerance and query routing. Incorrect snitch settings can lead to uneven data distribution and reduced availability.

Batches group multiple mutations into a single atomic operation for the same partition. However, cross-partition batches are not atomic and can impact performance. Best practices include limiting batch size, batching only related rows, and avoiding cross-partition batches unless necessary.

Lightweight transactions use the Paxos protocol to provide linearizable consistency for conditional updates (e.g., compare-and-set). LWTs are slower and more resource-intensive than regular writes, so they should be used sparingly for operations requiring strong consistency, such as unique constraints.

System tables store metadata about schema, topology, and cluster state. They can be queried to monitor node status, schema versions, repair history, and more, aiding in troubleshooting and cluster management.

During bootstrap, a new node streams data from existing nodes to acquire its share of data. Decommission removes a node and streams its data to others. Risks include increased network and disk I/O, potential data inconsistency if not coordinated properly, and temporary performance impact.

Cassandra replicates data across multiple data centers using NetworkTopologyStrategy. Challenges include increased write latency, consistency management, and network bandwidth usage. Proper configuration of replication factor and consistency levels is essential for balancing performance and durability.

Read repair detects and fixes inconsistencies between replicas during read operations by comparing data and updating out-of-date replicas. While it improves consistency, it can increase read latency and network traffic, especially at higher consistency levels.

Cassandra relies on JVM heap for in-memory operations. Heap size should be set to 8-16GB to avoid long GC pauses. Use G1GC or CMS for garbage collection, monitor GC logs, and avoid excessive heap allocation to maintain low-latency performance.

UDTs allow you to define custom, reusable data structures within tables, enabling more complex and nested data models. They improve schema clarity and reduce the need for multiple tables, but should be used judiciously to avoid large partitions.

SSTables are immutable, sorted files that enable efficient sequential reads and compaction. Indexes and bloom filters accelerate lookups, while compaction merges SSTables to reclaim space and remove obsolete data.

Cassandra supports pluggable authentication (e.g., PasswordAuthenticator), role-based access control for authorization, and encryption for data in transit (SSL/TLS) and at rest. Properly configuring these features is essential for securing sensitive data and meeting compliance requirements.