Apache Cassandra

📋 Overview

Apache Cassandra is an open-source, highly scalable, distributed NoSQL database designed to handle massive amounts of data across many commodity servers. It offers High Availability with no single point of failure and is uniquely optimized for Write-Heavy workloads. Based on a masterless architecture, Cassandra allows for seamless multi-region replication and linear scalability.

---

🏗️ Core Principles & Characteristics

• Masterless Architecture: Every node in the cluster is identical; there is no "Leader" or "Master" node. Any node can handle any read or write request (Gossip Protocol).
• LSM-Tree Storage: Optimized for sequential writes. Data is written to a Commit Log and Memtable in RAM, then flushed to immutable SSTables on disk.
• Partitioning: Data is distributed across the cluster using a Partition Key, which determines which node stores the data (Consistent Hashing).
• Tunable Consistency: Allows the developer to decide the consistency level per-query (e.g., ANY, ONE, QUORUM, ALL).
• High Availability (AP): In CAP Theorem terms, Cassandra is primarily an AP system, prioritizing availability and partition tolerance over immediate consistency.

---

⚖️ Trade-offs: Pros & Cons

• Pros:
  • Linear Scalability: You can increase throughput by simply adding more nodes to the cluster.
  • No Single Point of Failure: If a node goes down, the cluster continues to function without a manual failover.
  • Global Distribution: Excellent native support for multi-datacenter replication.
• Cons:
  • No Joins or Subqueries: Data must be denormalized; you must design your schema specifically for your queries.
  • Compaction Overhead: Background maintenance (merging SSTables) can be CPU and I/O intensive.
  • Eventual Consistency: Reads may return stale data unless you use high consistency levels (which increases latency).

---

🌍 Real-World Implementation

• Netflix: Uses Cassandra to store user viewing history and personalized metadata across several global AWS regions.
• Uber: Stores high-velocity GPS coordinates and trip data from millions of active drivers.
• IoT Platforms: Ingesting and storing millions of sensor events per second from smart devices.
• Messaging: Powering the chat history and activity feeds for high-scale communication apps.

---

💡 Interview "Gotchas" & Tips

• Query-First Design: Emphasize that in Cassandra, you don't normalize. You create one table per query/view. "Disk is cheap, but joins are expensive."
• Tombstones: Deleting data doesn't remove it; it creates a "Tombstone." Too many deletes can lead to slow reads and "Tombstone Overload."
• Consistency vs. Latency: Be ready to explain the trade-off: QUORUM is safer but slower; ONE is faster but riskier.
• Secondary Indexes: Generally discouraged for high-cardinality data; recommend using a search engine like Elasticsearch instead.

---

📐 Suggested Architecture Primitives

• Data Model: CQL (Cassandra Query Language)—looks like SQL but doesn't support joins or complex transactions.
• Infrastructure: Typically deployed on large clusters of high-memory VMs with SSD storage.
• Replication Factor (RF): A standard RF is 3, meaning every piece of data is stored on three different nodes.