STRONG - Guaranteed Consistency with QUORUM
🛡️ Master QUORUM, R+W>RF formula, and when you absolutely need guaranteed reads!
📖 Stripe: When Strong Consistency is Non-Negotiable
Stripe processes billions of dollars in payments annually with millions of transactions per day. The challenge? You cannot afford to lose payment data. Ever. Challenge: If they used eventual consistency (ONE) = risk of silent data loss. Concurrent writes could conflict. Last-Write-Wins could discard payment! Customer charged but no record = disaster. Regulatory violation. Lawsuits. The requirement: Every payment must be immediately consistent across all replicas. No stale reads. No conflicts. No data loss. Stripe's solution: Strong consistency (QUORUM + QUORUM) for all financial transactions! The guarantee: R + W > RF = overlap guaranteed. Every read returns the latest write. No ghost data. No conflicts. Result: Zero payment data loss, regulatory compliance maintained, customer trust preserved, 12-18ms latency (acceptable for payments). The trade-off: Slightly slower than eventual (12ms vs 3ms), but worth it for financial accuracy. Half the throughput (25k vs 50k ops/sec), but payments aren't that high volume. Stripe Engineering: "For payment data, strong consistency isn't optional - it's mandatory. The R+W>RF formula gives us mathematical certainty that we'll never read stale financial data. 12ms is a small price to pay for guaranteed accuracy!"
💻 Interactive Strong Consistency Simulator
See strong consistency guarantees in action! Watch QUORUM prevent stale reads!
🛡️ Strong Consistency Scenarios - Click to Explore:
⚖️ Click scenarios above to see QUORUM guarantees
✓ Learn R+W>RF formula and overlap principle
🛡️ The Strong Guarantee
Strong consistency means: You always read the most recent write. No stale data. No ghost updates. No conflicts. QUORUM achieves this through the R+W>RF formula - by querying the majority on reads and writes, we guarantee overlap. At least one replica in both sets will have the latest data. This is Cassandra's rock-solid guarantee for critical data!
🛡️ What is Strong Consistency?
Imagine you have three bank vaults storing your money. With strong consistency, when you deposit money, you wait until at least 2 of 3 vaults confirm they have your money. When you check your balance, you ask 2 of 3 vaults and take the latest value. Because you check 2 and updated 2 (out of 3 total), at least 1 vault MUST be in both sets - that vault has the correct balance! You're guaranteed to never see stale money!
🏦 The Bank Vault Analogy
You have $1,000 in 3 bank vaults: Vault A, Vault B, Vault C.
With Eventual Consistency (ONE):
• You deposit $500 → Only Vault A confirms (instant!)
• You immediately check balance → Ask Vault B
• Vault B shows $1,000 (old!) → "Where's my $500?!"
• Your $500 is "in transit" to Vaults B and C
• Eventually all vaults show $1,500 ✓
With Strong Consistency (QUORUM):
• You deposit $500 → Wait for 2 of 3 vaults to confirm (12ms)
• Vaults A and B both confirm $1,500 ✓
• You immediately check balance → Ask 2 of 3 vaults
• Guaranteed: At least 1 of the 2 you ask was updated!
• If you ask A+B: Both say $1,500 ✓
• If you ask A+C: A says $1,500 (latest!) ✓
• If you ask B+C: B says $1,500 (latest!) ✓
• Always see $1,500! Never stale!
The Math:
Updated vaults (W) = 2
Queried vaults (R) = 2
Total vaults (RF) = 3
R + W = 2 + 2 = 4
4 > 3 ✓ OVERLAP GUARANTEED!
Cassandra's QUORUM works exactly like this: Wait for majority on writes, query majority on reads = always see latest value!
Guaranteed Fresh Reads
Promise: Always read most recent write
Mechanism: R + W > RF overlap guarantee
QUORUM: 2 write + 2 read = 4 > 3 (RF) ✓
Result: Never stale data
Use case: User profiles, orders, critical data
Cost: Slower (12ms vs 3ms) but worth it!
Conflict Prevention
Problem prevented: Concurrent write conflicts
With ONE: Two users write → one lost (LWW)
With QUORUM: Both writes see each other
Behavior: Last write truly wins (no silent loss)
Critical for: Shopping carts, balances, inventory
Benefit: No silent data loss!
Linearizability
Definition: Operations appear atomic and ordered
Guarantee: If A writes then B reads, B sees A's write
QUORUM: Provides this guarantee
Causality: Respects happens-before relationships
Real-world: User updates → refresh → sees update
Compare: Eventual can show old value
💡 Key Difference from Eventual
Eventual (ONE): "If you stop writing, replicas will eventually agree." (20-100ms convergence, stale reads possible)
Strong (QUORUM): "You always read the latest write, immediately." (no convergence needed, never stale!)
The cost? Latency increases from 3ms to 12ms, and throughput drops from 50k to 25k ops/sec. But for critical data - profiles, orders, payments - it's absolutely worth it!
⚖️ QUORUM Deep-Dive: The Majority Rule
QUORUM means "majority of replicas" - more than half! It's the sweet spot between ONE (too weak) and ALL (too strict).
Majority Calculation
Formula: QUORUM = ⌈RF / 2⌉ (ceiling of half)
RF=3: QUORUM = ⌈3/2⌉ = ⌈1.5⌉ = 2
RF=5: QUORUM = ⌈5/2⌉ = ⌈2.5⌉ = 3
RF=7: QUORUM = ⌈7/2⌉ = ⌈3.5⌉ = 4
Pattern: Always more than half!
Why: Guarantees overlap for R+W>RF
Performance Profile
Latency: 12-18ms (waits for majority)
Throughput: 25,000 writes/sec per node
Comparison: 4x slower than ONE, 3x faster than ALL
Network: Multiple replicas = more network round-trips
Sweet spot: Balance between speed and consistency
Production: 99% of strong consistency use cases
Fault Tolerance
RF=3: Can lose 1 node (33% failure tolerance)
RF=5: Can lose 2 nodes (40% failure tolerance)
RF=7: Can lose 3 nodes (43% failure tolerance)
Formula: Can lose ⌊RF/2⌋ nodes
Better than ALL: ALL fails if ANY node down!
Production: RF=3 standard (lose 1 node = OK)
Write Behavior
Process: Coordinator sends to all RF replicas
Wait: Must receive ACKs from QUORUM (majority)
RF=3: Waits for 2 of 3 ACKs (12ms typical)
Background: Third replica updates async
Success: Client gets response after majority confirms
Failure: If can't reach majority = write fails
Read Behavior
Process: Coordinator queries QUORUM replicas
RF=3: Queries 2 of 3 replicas (random selection)
Compare: Gets responses, compares timestamps
Return: Returns value with latest timestamp
Repair: Updates stale replicas in background
Guarantee: Always returns latest write!
Why QUORUM Works
Math: R=2, W=2, RF=3 → 2+2=4>3 ✓
Overlap: Write set (2) + Read set (2) = 4 replicas
But only 3 exist: Pigeonhole principle!
Guarantee: At least 1 replica in BOTH sets
That replica: Has the latest write
Result: Read always returns latest value!
🗳️ QUORUM Like Voting
Think of QUORUM like a voting system with 3 judges:
Decision (Write with QUORUM):
• Need majority (2 of 3) to pass a ruling
• Judge A votes YES (5ms)
• Judge B votes YES (12ms) → Decision passed! ✓
• Judge C still deliberating (doesn't matter!)
• Majority reached = decision is law
Query (Read with QUORUM):
• Need to ask majority (2 of 3) what the law is
• Ask Judges A + B: Both say "Law XYZ" ✓
• Ask Judges A + C: A says "Law XYZ", C says "Law ABC" → A is newer! ✓
• Ask Judges B + C: B says "Law XYZ", C says "Law ABC" → B is newer! ✓
• No matter which 2 you ask, you always get the latest law!
Why it works:
• Passed decision with 2 judges (A + B)
• Query 2 of 3 judges
• At least 1 of queried judges MUST be from the passing set!
• That judge has the latest decision
• Mathematical guarantee!
💡 Why Not Use ALL Instead?
ALL seems safer - why not wait for all replicas?
Problem with ALL: If ANY single node is down → entire write fails! In a 3-node cluster with ALL, if 1 node crashes = 0% availability for writes. With QUORUM, you can lose 1 node and still have 100% availability! QUORUM is the perfect balance: Strong consistency + Good availability. This is why 99% of production systems use QUORUM, not ALL!
🧮 R+W>RF Formula: Visual Proof
✅ The Golden Rule
If R + W > RF → You have strong consistency! This is a mathematical guarantee, not just a best-effort promise. The overlap principle ensures that at least one replica in your read set will have been part of your write set, giving you the latest value. For most production systems: QUORUM + QUORUM (R=2, W=2, RF=3 → 2+2=4>3 ✓) is the perfect balance of strong consistency, good performance, and reasonable fault tolerance!
✅ What Strong Consistency Guarantees
Strong consistency with QUORUM provides mathematical guarantees that eventual consistency cannot match!
Never Stale Reads
Promise: Every read returns most recent write
Mechanism: R+W>RF overlap guarantee
Probability: 100% (not 66% like eventual!)
User experience: Update → refresh → see update ✓
No ghost data: Never flip-flop old/new
Business impact: Reliable UX, happy users
Linearizability
Definition: Operations appear in global order
Guarantee: If A completes before B starts, B sees A's effect
Real-world: Alice writes, Bob reads, Bob sees Alice's write
Causality: Respects happens-before relationships
Compare: Eventual can violate causality
Critical for: Coordinated multi-step operations
Conflict-Free Reads
Problem prevented: Reading mid-conflict state
With ONE: Can read partially replicated data
With QUORUM: Always read fully replicated majority
Consistency: All readers see same value
No surprises: Predictable behavior
Business value: No user confusion
Immediate Consistency
No convergence wait: Consistent immediately!
Compare eventual: 20-100ms convergence window
QUORUM: Consistent as soon as write completes
User experience: Write completes = everyone sees it
No race conditions: No timing-dependent bugs
Simplifies testing: Predictable behavior
Atomic Operations
Guarantee: Operations complete or fail, no partial
With QUORUM: Majority confirms = committed
Failure handling: Can't reach majority = write fails
No limbo: Data either there or not, never partial
Critical for: Multi-step transactions
Business value: No data corruption
Read-Your-Writes
Promise: If you write then read, you see your write
User expectation: "I just saved, where is it?!"
QUORUM: Always see your own updates ✓
ONE problem: Might read from stale replica ❌
Critical for: User-facing data (profiles, posts)
UX impact: No user confusion!
🎯 Strong vs Eventual: Real-World Impact
User updates their email address:
With Eventual (ONE):
• User types new email → clicks Save
• Write succeeds in 3ms ✓
• User refreshes page immediately
• Sees OLD email! "Did it save?!"
• Refreshes again → sees NEW email (confusing!)
• Support ticket: "Your site is broken!"
• Result: Angry user, lost trust
With Strong (QUORUM):
• User types new email → clicks Save
• Write waits for majority (12ms) ✓
• User refreshes page immediately
• Sees NEW email! Perfect! ✓
• Refreshes again → still sees NEW email (consistent!)
• User happy, app feels reliable
• Result: Happy user, trust maintained
The cost? 9ms additional latency (12ms vs 3ms). Worth it for user-facing data! User doesn't notice 12ms, but they DEFINITELY notice ghost data!
💡 What Strong Consistency Does NOT Guarantee
Important limitations:
• Does NOT prevent concurrent writes: Two users can still write concurrently, Last-Write-Wins still applies (use LWT for true serializability)
• Does NOT guarantee global ordering: Different clients may observe writes in different orders (unless using SERIAL)
• Does NOT prevent network partitions: During split-brain, minority partition becomes unavailable
• Does NOT make writes faster: Actually 4x slower than ONE due to waiting for majority
QUORUM gives you strong consistency (no stale reads), but it's not a silver bullet. For truly atomic operations, consider Lightweight Transactions (LWT)!
🎯 When You NEED Strong Consistency
Not all data needs QUORUM. Here's when strong consistency is essential vs when eventual is fine!
NEEDED: User Profiles
Data: Email, username, bio, settings
Why QUORUM: User updates → refreshes → must see update!
ONE problem: Ghost data = "Where's my change?!"
User tolerance: Zero for profile updates
Volume: Moderate (10k updates/sec manageable)
Latency OK: 12ms acceptable for profile saves
Verdict: Use QUORUM! ✓
NEEDED: Shopping Cart
Data: Items in cart, quantities
Why QUORUM: Prevent item loss from concurrent adds
ONE problem: Add iPhone + MacBook → one lost (LWW!)
Business impact: Lost sales, support tickets
User expectation: Cart = reliable staging area
Better: Use append-only + QUORUM
Verdict: Use QUORUM! ✓
NEEDED: Financial Data
Data: Payments, balances, transactions
Why QUORUM: Cannot afford data loss or stale reads
ONE problem: Concurrent transactions = money lost!
Regulatory: Compliance requires consistency
Even better: Use QUORUM + LWT for atomicity
Performance: Financial operations not high-volume
Verdict: Use QUORUM! (or ALL) ✓
NOT NEEDED: Analytics Events
Data: Pageviews, clicks, impressions
Why ONE OK: Approximate counts acceptable
Volume: Massive (100k+ events/sec)
QUORUM cost: Would kill throughput!
Staleness: "12,347 vs 12,351 views" = who cares?
Latency critical: Must not block app flow
Verdict: Use ONE! ✓
NOT NEEDED: Search Cache
Data: Cached search results
Why ONE OK: It's a cache! Stale = refresh
Volume: Very high (millions of searches/sec)
QUORUM cost: 4x slower for no benefit
Staleness impact: Missing result → next search finds it
User expectation: Caches can be stale
Verdict: Use ONE! ✓
NOT NEEDED: Like Counters
Data: Post likes, view counts, engagement metrics
Why ONE OK: Approximate counts perfectly fine
Volume: Billions of likes per day
QUORUM impact: Would limit scalability
Staleness: "12.3k vs 12.4k" = immaterial
User expectation: Counts can lag slightly
Verdict: Use ONE! ✓
⚖️ Decision Framework
Ask these questions:
1. Will users notice stale reads? (Yes → QUORUM, No → ONE)
2. Would stale data cause confusion? (Yes → QUORUM, No → ONE)
3. Is this user-facing critical data? (Yes → QUORUM, No → ONE)
4. Would concurrent writes cause data loss? (Yes → QUORUM, No → ONE)
5. Is volume moderate (<50k writes/sec)? (Yes → QUORUM OK, No → consider ONE)
6. Is data approximate/regenerable? (Yes → ONE OK, No → QUORUM)
General rule: When in doubt, start with QUORUM. Only optimize to ONE if you're certain staleness is acceptable and volume demands it!
⚖️ Trade-offs: Strong Consistency Costs
Strong consistency isn't free. Understanding the trade-offs helps you make smart decisions!
Latency Cost
ONE: 3-5ms (single replica ACK)
QUORUM: 12-18ms (majority ACK)
ALL: 40-80ms (all replicas ACK)
Cost: 4x slower than ONE!
Impact: 12ms noticeable for high-frequency ops
Acceptable for: User-facing updates (profile, cart)
Too slow for: Analytics, high-volume counters
Throughput Cost
ONE: 50,000 writes/sec per node
QUORUM: 25,000 writes/sec per node
ALL: 8,000 writes/sec per node
Cost: 50% throughput reduction!
Why: More replicas = more coordination
Acceptable for: Moderate volume (<50k/sec)
Problem for: High-volume data (>100k/sec)
Availability Cost
ONE (RF=3): Works with 2 nodes down
QUORUM (RF=3): Works with 1 node down
ALL (RF=3): Works with 0 nodes down!
Cost: Lower fault tolerance
Risk: Can't reach majority = writes fail
Mitigation: Higher RF (RF=5 can lose 2 nodes)
Production: RF=3 + QUORUM = acceptable
Consistency Benefit
ONE: 66% stale read probability
QUORUM: 0% stale read probability!
ALL: 0% stale but overkill
Benefit: Never see ghost data
UX impact: Users always see their updates
Business value: Reliable, trustworthy app
Worth it for: User-facing critical data
Predictability Benefit
ONE: Unpredictable convergence (20-100ms)
QUORUM: Immediate consistency!
Benefit: No timing-dependent bugs
Testing: Easier to test (no race conditions)
Development: Simpler reasoning about state
Operations: Fewer "weird" production issues
Saves: Engineering time debugging
Business Value
ONE: Fast but confusing UX
QUORUM: Reliable, trustworthy feel
User trust: App "just works" consistently
Support tickets: Fewer "my data disappeared!" tickets
Reputation: Professional, reliable app
Conversion: Users trust app with critical data
ROI: Worth latency cost for critical features
💰 Cost-Benefit Analysis: Real Numbers
E-commerce platform: 1 million users, 100k orders/day
Scenario 1: User Profiles with ONE (eventual)
• Latency: 3ms ✓
• Throughput: 50k updates/sec ✓
• Problem: Users update email → refresh → see OLD email
• Support tickets: 500/day "My update didn't save!"
• Cost: 500 tickets × $5/ticket × 365 days = $912,500/year
• User churn: 2% abandon due to frustration
• Lost revenue: 20,000 users × $50 average order = $1M/year
• Total cost: $1.9M/year
Scenario 2: User Profiles with QUORUM (strong)
• Latency: 12ms (9ms slower, but user doesn't notice!)
• Throughput: 25k updates/sec (still more than enough!)
• Problem: None! Users always see their updates ✓
• Support tickets: 50/day (unrelated issues)
• Cost: 50 tickets × $5/ticket × 365 days = $91,250/year
• User churn: 0% from consistency issues ✓
• Lost revenue: $0 ✓
• Total cost: $91,250/year
Net benefit of QUORUM: $1.8M/year savings!
The 9ms latency increase costs nothing, but the consistency guarantee saves millions in support costs and lost revenue. This is why QUORUM is worth it for user-facing data!
⚖️ When Is The Cost Too High?
Use ONE instead of QUORUM when:
• Volume > 50k writes/sec: QUORUM throughput limit would require more nodes
• Latency < 5ms required: Real-time systems where 12ms is too slow
• Approximate data OK: Analytics, counters, metrics where staleness acceptable
• Cache/regenerable: Data that can be refreshed if stale
• Non-user-facing: Background jobs, internal metrics
For everything else (user profiles, orders, payments, critical business data) → QUORUM is worth it!
🏢 How Real Companies Use Strong Consistency
💳 Stripe: QUORUM for Payment Integrity
Scale: Billions in payments annually, millions of transactions/day
Requirement: Zero data loss, regulatory compliance, audit trail
Payment Transactions (QUORUM + QUORUM):
• Every payment written with CL=QUORUM
• Waits for 2 of 3 replicas (12-18ms)
• Read with QUORUM ensures immediate consistency
• Customer charged = payment record immediately visible
• Why: Cannot afford stale reads showing "payment not found"
• Why: Regulatory requirements for financial data
• Cost: 12-18ms latency acceptable for payment processing
Customer Metadata (QUORUM):
• Email, billing address, payment methods
• Written with QUORUM (12-15ms)
• Users expect immediate updates
• "I just updated my card, why doesn't it show?"
Even Stronger: Idempotency Keys (ALL):
• Prevent duplicate charges
• Written with CL=ALL (40ms)
• Worth the cost to prevent double-charging customers
• Critical for financial integrity
But Analytics (ONE):
• Payment success rates, metrics, dashboards
• HIGH volume (millions of events/sec)
• Approximate counts fine for internal analytics
• ONE allows massive throughput
Result: Zero payment data loss, regulatory compliance, customer trust maintained. Stripe's engineering: "Strong consistency for financial data isn't optional - it's mandatory. The R+W>RF formula gives us mathematical certainty!"
🏨 Booking.com: QUORUM for Zero Double-Bookings
Scale: 1.5M+ properties, millions of bookings/day
Challenge: Prevent double-booking same room
Bookings/Reservations (QUORUM + LWT):
• Each booking: QUORUM write (15ms)
• Checks room availability with Lightweight Transactions
• IF room available THEN book ELSE fail
• Prevents concurrent users booking same room
• Why QUORUM: Immediate consistency = no race conditions
• Why LWT: Atomic check-and-set operation
• Cost: 50ms total (QUORUM + LWT overhead)
• Worth it: Zero double-bookings = no angry customers!
Room Availability Count (QUORUM):
• "3 rooms left!" on listing page
• Written with QUORUM to prevent overselling
• Two users see "1 room left" simultaneously
• Both try to book → LWT ensures only one succeeds
• Other sees "Sorry, room just booked"
User Booking History (QUORUM):
• "My Bookings" page
• User books hotel → refreshes "My Bookings"
• Must see their new booking immediately!
• QUORUM guarantees they see it
But Search Results Cache (ONE):
• Hotel search results
• HIGH volume (millions of searches/sec)
• Stale cache = just search again
• ONE allows fast searches (3-5ms)
Result: Zero double-bookings, reliable inventory, customer satisfaction. Booking.com: "For inventory management, strong consistency is non-negotiable. The 50ms cost of QUORUM+LWT is nothing compared to the cost of unhappy customers!"
🏦 Banking App: ALL for Critical Balances
Scale: 5M+ users, 10M+ transactions/day
Requirement: Absolute accuracy for account balances
Account Balances (ALL + ALL):
• Every balance update: CL=ALL (40ms)
• Waits for ALL 3 replicas to acknowledge
• Read with CL=ALL for absolute certainty
• Why ALL: Financial regulations require ALL replicas
• Why ALL: Audit trail must be complete
• Cost: 40ms latency for balance updates
• Acceptable: Balance updates not high-frequency
Transactions (QUORUM + LWT):
• Deposits, withdrawals, transfers
• QUORUM write (15ms) + LWT for atomicity
• Prevents concurrent transactions causing errors
• IF balance sufficient THEN withdraw ELSE fail
• Result: No overdrafts, no duplicate charges
User Profile (QUORUM):
• Email, phone, address
• Not as critical as balances but still important
• QUORUM sufficient (12ms)
• Users expect immediate profile updates
But Login Attempts Log (ONE):
• Track failed login attempts
• HIGH volume event logging
• Approximate counts OK for security monitoring
• ONE allows fast logging without blocking logins
Result: Zero balance discrepancies, regulatory compliance, customer trust. Bank CTO: "For financial data, we use ALL. Yes it's slower, but accuracy is non-negotiable. Users will wait 40ms for absolute certainty their money is safe!"
✅ Best Practices for Strong Consistency
1. Default to QUORUM for User Data
Rule: Start with QUORUM for all user-facing data
Reason: Users expect their updates to be visible
Optimize: Only downgrade to ONE if proven necessary
Test: Measure actual throughput needs first
Don't assume: "I need ONE for performance"
Reality: 25k ops/sec often enough!
2. Match Read and Write CL
Pattern: If write=QUORUM, read=QUORUM
Why: Ensures R+W>RF for strong consistency
Don't: Write QUORUM but read ONE
Result: Still get stale reads! (1+2=3 ≤ 3 ❌)
Exception: Write=ALL + Read=ONE is strong
But: QUORUM+QUORUM is better balance
3. Monitor QUORUM Latency
Metric: P99 write latency for QUORUM
Healthy: 12-20ms typical
Alert: >50ms = investigate!
Causes: Slow nodes, network issues, GC pauses
Tool: nodetool tablestats, prometheus
Action: Find slow replica, investigate
4. Use LWT for True Atomicity
When: Concurrent writes to same key likely
Pattern: IF condition THEN update ELSE fail
Example: Shopping cart, inventory, bookings
Cost: 4x slower than plain QUORUM (50ms)
Worth it: Prevents data loss from conflicts
Note: QUORUM alone doesn't prevent conflicts!
5. Test Failure Scenarios
Simulate: Kill 1 node in RF=3 cluster
Verify: QUORUM writes still succeed ✓
Simulate: Kill 2 nodes
Verify: QUORUM writes fail (can't reach majority)
Tool: Chaos engineering, nodetool stop
Production: Know failure modes before outage!
6. Consider RF=5 for Critical Data
RF=3: Can lose 1 node (33% tolerance)
RF=5: Can lose 2 nodes (40% tolerance)
QUORUM: Still 3 of 5 (same R+W>RF)
Benefit: Better availability during failures
Cost: More storage, more network
When: Critical financial/payment data
7. Don't Over-Use ALL
ALL feels safer: But it's rarely necessary
Problem: ANY node down = 0% availability
QUORUM better: Strong + good availability
Use ALL only: Regulatory requirement (audit logs)
Use ALL only: Financial compliance mandates
Otherwise: QUORUM is the right choice
8. Document Consistency Choices
For each table: Document why QUORUM chosen
Include: Criticality, volume, user expectations
Review: Quarterly consistency strategy audit
Share: Team understanding critical
Update: As requirements evolve
Prevent: Accidental downgrades to ONE
9. Benchmark Before Optimizing
Don't assume: "QUORUM too slow for my case"
Measure: Actual throughput with QUORUM
Compare: Against requirements (not ONE)
Often: 25k ops/sec sufficient!
Optimize: Only if proven bottleneck
Remember: Correctness > speed
🚨 Common Mistakes to Avoid
- ❌ Using ONE for user profiles: "It's faster!" → Users see ghost data, confusion
- ❌ Write QUORUM but read ONE: Still get stale reads! R+W≤RF ❌
- ❌ Using ALL everywhere: Poor availability, any node down = fail
- ❌ Not testing node failures: Surprise outages in production
- ❌ Assuming QUORUM "too slow": Measure first, optimize only if needed
- ❌ Forgetting LWT for conflicts: QUORUM prevents stale reads, not conflicts
Responsive Ad