Cassandra is famously 'AP' from CAP, but the real story is per-query tunability. The replication factor + consistency level pair gives you fine-grained control over how strong your reads and writes are — and what fails when a node goes down.
RF and CL recap
RF (replication factor) is set per keyspace: how many copies of each partition exist. CL (consistency level) is set per query: how many of those copies must acknowledge for the operation to count. RF=3, CL=QUORUM for both reads and writes gives you strong consistency at the cost of one-node tolerance.
Strong consistency without consensus
If R + W > RF then reads see the latest write — guaranteed. QUORUM + QUORUM with RF=3 satisfies this (2+2>3). LOCAL_QUORUM does the same within a datacenter at lower latency. You get linearizable-feeling behavior without Paxos.
When you choose AP
CL=ONE writes + CL=ONE reads: lowest latency, highest availability — keep accepting writes even with two of three nodes down. Acceptable for write-heavy telemetry, clickstream, IoT. Not acceptable for balances or auth tokens.
LWT (Paxos) for when AP isn't enough
Lightweight transactions use Paxos for compare-and-set. ~4x slower than a normal write. Use sparingly: unique-username checks, idempotency keys, leader election. Don't sprinkle them around.
Hinted handoff and read repair
Down replicas get 'hints' stored on coordinator nodes; replayed on recovery (3-hour default window). Read repair fixes divergence opportunistically on read. Anti-entropy repair (nodetool repair) is the safety net — run weekly on every node.