Consistency Models and Replication Trade-offs

Consistency Options
Document databases offer tunable consistency: choose between strong guarantees with higher latency or eventual consistency with lower latency and potential stale reads. Single document operations are typically strongly consistent (read your own write immediately). Cross-document or cross-shard operations introduce trade-offs.
Write Concerns
Write concern controls durability. w:1 acknowledges after the primary persists, typically 5ms latency, but risks data loss if the primary crashes before replicating. w:majority waits for a majority of replicas to acknowledge, ensuring survival of failures but adding replication RTT (Round-Trip Time, the time for data to travel to replicas and acknowledgment to return).
In a single region, majority adds low single-digit milliseconds. Across regions, expect 30-100ms additional latency. For critical data (financial transactions, bookings), majority is non-negotiable despite the cost.
Read Preferences
Read preferences control where reads execute. Reading from the primary guarantees the latest data but concentrates load. Reading from secondaries distributes load but may return stale data if replication lags. Applications can route non-critical reads to secondaries while keeping critical reads on the primary.
Replication Lag
Replication lag is the delay between a write on the primary and its arrival on secondaries. Under normal load, lag is under 1 second. During write spikes or network issues, lag can grow to 10+ seconds. A user writing then immediately reading from a lagging secondary sees stale data. Monitor lag and shed traffic from lagging replicas.
Failover Behavior
When the primary fails, the replica set elects a new primary, typically taking 5-15 seconds. During this window, writes fail and reads may pause. Applications need retry logic with exponential backoff (progressively longer waits between retries: 100ms, 200ms, 400ms) and idempotency tokens (unique IDs ensuring duplicate requests are detected and handled safely).

💡 Key Takeaways

✓Single document ops are strongly consistent; cross-document transactions add latency

✓w:majority ensures durability but adds 5-100ms depending on replica distance

✓Reading from secondaries distributes load but risks stale data during replication lag

✓Replication lag can spike to 10+ seconds during write bursts, causing stale reads

✓Failovers take 5-15 seconds; applications need retry logic and idempotency tokens

📌 Interview Tips

1Discuss write concern choice: majority for critical data, w:1 for high-throughput non-critical writes

2Mention replication lag monitoring when discussing consistency trade-offs

3Explain idempotency tokens for handling retries during failovers

← Back to Document Databases (MongoDB, Firestore) Overview