Tunable Consistency per Query

"What consistency does our database give us?" is the wrong question. Different queries need different guarantees. A user's password change must be strongly consistent (next login should see the new hash). A like-count display can be eventually consistent (15 seconds of staleness invisible).

Forcing strong consistency on everything is expensive. Forcing weak consistency on everything is unsafe. Tunable per-query consistency — choosing the level at the call site, per request — is how Dynamo-style and modern distributed databases let you have both. The interview-grade answer to "is this CP or AP?" is "it depends per query."

Two settings per operation, both relative to N replicas:

• W = how many replicas must ack before write returns success.
• R = how many replicas must respond before read returns.

Magic inequality: W + R > N guarantees any read overlaps with the latest write — strong consistency. W + R ≤ N = eventual consistency. See quorum.

Common settings on N=3:

The real superpower: pick the level per call site, not per database.

// Cassandra example
session.execute(insert(orders), ConsistencyLevel.QUORUM);  // strong
session.execute(insert(view_log), ConsistencyLevel.ONE);   // eventual

session.execute(select(user_profile), ConsistencyLevel.QUORUM);  // strong read
session.execute(select(like_count), ConsistencyLevel.ONE);       // eventual

Same DB, same connection, same cluster. The application code chooses per query. Each query pays only what it needs.

Modern systems offer a richer menu than just W/R numbers:

• Linearizable — strongest. Reads see effects in real-time order. Cassandra's SERIAL, Spanner default.
• Sequential / strong-after-read — operations from any one client appear in order. Most apps' actual need.
• Bounded staleness — "may be up to 5 seconds stale." Predictable upper bound. Useful for "this dashboard updates every 5s" UX.
• Session consistency / read-your-writes — within one user's session, reads always see their writes. Implemented via session-pinned routing or version vectors.
• Eventual — converges in finite time, no specific bound. Cheapest.

DynamoDB exposes "strong" vs "eventual" reads as a flag per request. CockroachDB / Spanner default to linearizable but allow per-transaction BOUNDED STALENESS for read-only reporting queries — 100× faster for analytics that don't need real-time.

Per-query consistency is enabled by a smart driver/coordinator:

1. App makes call with consistency level annotation.
2. Coordinator picks N replicas owning the key (via consistent hashing).
3. Sends request to enough of them to satisfy W or R.
4. Waits for that many acks; returns.
5. Async fires off requests to remaining replicas (for read repair / write fan-out beyond W).

The cost shows up in latency. Strong reads (R=2) wait for the 2nd-fastest replica to respond. P99 latency follows the slow tail of the slowest replica in the quorum. This is why hedging and aggressive timeout tuning matter so much.

News feed mixes QUORUM writes (post creation) with ONE reads (feed display). E-commerce checkout uses QUORUM for orders + ONE for product-view-count updates. Google Docs uses linearizable for OT operations + bounded staleness for "saved" indicators.