# 🐘 Cassandra & ScyllaDB

## Overview

Apache Cassandra is a distributed wide-column NoSQL database designed for high availability and linear scalability with no single point of failure. Inspired by the Amazon Dynamo paper (2007) and Google Bigtable. ScyllaDB is a C++ reimplementation compatible with the Cassandra protocol, with drastically lower latency and higher throughput.

## Architecture (Dynamo-inspired)

### Consistent hashing

Data is divided on a hash ring, each node is responsible for a token range:

```text
   0 ─── node A ─── hash(key1)
         │
   90 ─── node B ─── hash(key2)
         │
  180 ─── node C ─── hash(key3)
         │
  270 ─── node D ─── hash(key4)
```

- Adding/removing a node affects only K/N keys (thanks to virtual nodes)
- **Virtual nodes** (vnodes) — each physical node has ~100-200 tokens on the ring (more even distribution)

### Quorum (N, R, W)

- N = replication factor (typically 3)
- R = read quorum (typically 2)
- W = write quorum (typically 2)
- Condition: R + W > N (for strong-ish consistency)
- **Sloppy quorum** — when a node is unavailable, data is temporarily stored on another
- **Hinted handoff** — temporary write with hint, data transferred upon recovery

### Gossip protocol

Decentralized dissemination of membership information — each node periodically communicates with 1-3 random nodes. No central point of failure.

### Vector clocks

Capturing causality of object versions. On conflict (partition merge), both versions are returned — application merges.

### Merkle trees

Anti-entropy — hash tree for detecting divergence between replicas. Fast detection of which data ranges differ.

### Write path

```text
Client → Coordinator → [1. Write to commit log (disk)]
                       [2. Write to memtable (RAM)]
                       [3. Acknowledge client]
                       → [4. Flush memtable → SSTable (periodically)]
                       → [5. Compaction (merge SSTables)]
```

### Read path

```text
Client → Coordinator → [1. Check bloom filter]
                       [2. Check row cache / key cache]
                       [3. Read from SSTable (disk)]
                       [4. Merge with memtable]
                       [5. Repair if stale (read repair)]
```

## Cassandra vs ScyllaDB

| Feature | Cassandra | ScyllaDB |
|---------|-----------|----------|
| **Language** | Java (JVM) | C++ (seastar framework) |
| **Architecture** | Thread-per-connection | Shared-nothing, CPU sharding |
| **Latency** | 5-20 ms (typical) | 1-3 ms (typical) |
| **Throughput** | Good | 5-10× higher on same HW |
| **GC pauses** | Yes (JVM) | No (no GC) |
| **NUMA** | OS-dependent | Native NUMA aware |
| **Workload** | Standard | High-throughput, real-time |
| **Price** | Open source | Open source + Enterprise |

## Data model

- **Keyspace** = namespace (analogy to DB)
- **Table** = column definition (not schema-less)
- **Partition key** = hash key for ring distribution
- **Clustering columns** = ordering within a partition
- **Primary key** = Partition key + Clustering columns

## Recommendations — where Cassandra is better

| Area | Cassandra | Competition | Why Cassandra |
|------|-----------|-------------|---------------|
| **Write throughput** | Linear scaling, no master bottleneck | PostgreSQL (master writes) | Every node writes, no single point of failure |
| **Availability** | AP from CAP — always writable | MongoDB (CP, primary down = read-only) | "Always-writeable" philosophy |
| **Multi-DC** | Native, per-DC replication | CockroachDB (complex) | Simple configuration, latency-tolerant |
| **Time-series** | Wide-row model, TTL, compaction | InfluxDB (specialized) | Can combine with other workloads |
| **IoT / sensor data** | Linear scaling, no master | MongoDB (sharding complex) | Predictable performance under growth |
| **Geographic distribution** | Native multi-DC, hinted handoff | Spanner (vendor lock-in) | Open source, no dependencies |

### When to use Cassandra / ScyllaDB

- **IoT / sensor data ingest** — millions of writes/s, no data loss
- **Time-series at massive scale** — metrics, logs, event data
- **User activity history** — write-heavy workloads
- **Multi-DC applications** — data available in every location
- **Recommendation systems** — wide-row model for "what user has seen"
- **Message / event store** — high-throughput append with TTL

### When to use something else

- **Relations, JOINs, transactions** → PostgreSQL (Cassandra has no JOINs, limited transactions)
- **Full-text search** → Elasticsearch
- **Aggregation / OLAP** → ClickHouse (Cassandra is not an analytical DB)
- **Small data (< 100 GB)** → PostgreSQL (Cassandra overhead not worth it)
- **Frequent reads by secondary keys** → DynamoDB (SADA indexes) — Cassandra has limited secondary indexes

### ScyllaDB specific

ScyllaDB is advantageous when:
- You need 5-10× higher throughput on the same HW
- You have latency-sensitive workload (real-time scoring, ad-tech)
- You want to eliminate JVM/GC issues
- You need predictable performance (P99 < 5 ms)

## Sources

References, books, and standards: [sources/databases/sources.md](sources/databases/sources.md)

### Recommended reading

| Paper / Book | Authors | Description |
|--------------|---------|-------------|
| Dynamo: Amazon's Highly Available Key-value Store (SOSP 2007) | DeCandia et al. | Foundational paper for Cassandra architecture |
| Cassandra: The Definitive Guide (3rd ed.) | E. Hewitt | Comprehensive guide to deployment and operations |

*Last revision: 2026-06-03*