Consistency Models and Replication Trade-offs

Document databases offer tunable consistency: you 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), but cross-document or cross-shard operations introduce trade-offs. Understanding these knobs is critical for meeting correctness and latency Service Level Objectives (SLOs).

In MongoDB replica sets, write concern controls durability and acknowledgment. Write concern "w:1" acknowledges after the primary persists the write, giving low latency (typically 5ms) but risking data loss if the primary crashes before replication. Write concern "w:majority" waits for a majority of replica set members to acknowledge, ensuring the write survives failures but adding replication Round-Trip Time (RTT) to latency. In a single region with multiple Availability Zones (AZs), this adds low single-digit milliseconds; if secondaries span distant regions, expect 30 to 100ms additional latency. For critical financial or booking data, majority write concern is non-negotiable despite the latency cost.

Firestore multi-region instances synchronously replicate across regions for strong consistency, ensuring every read reflects the latest write globally. This adds tens of milliseconds to write latency compared to regional deployments due to cross-region quorum. The benefit is immediate global consistency: a user in Europe sees the same state as a user in the US without waiting for eventual propagation. The cost is that 10ms regional write becomes 50ms multi-region write.

Failover behavior matters operationally. MongoDB replica set elections typically take 5 to 15 seconds. During this window, writes targeting the primary fail, and clients with majority read concern may pause. Applications must implement retry logic with exponential backoff and idempotency tokens to handle transient failures. Monitor replication lag via operation timestamps: if a secondary falls 10 seconds behind during a write spike, reads from that secondary serve stale data. At scale, companies like Uber configure read preferences to balance load across secondaries while accepting bounded staleness for non-critical reads.

💡 Key Takeaways

•Single document operations are strongly consistent in most document databases, but cross-document transactions or multi-shard operations may relax guarantees depending on system and configuration

•MongoDB write concern majority ensures durability across replica set but adds replication RTT: 5ms becomes 10ms in single region, 50 to 100ms across distant regions, critical trade-off for global deployments

•Firestore multi-region synchronous replication guarantees strong consistency globally but writes take tens of milliseconds longer than regional deployments due to cross-region quorum coordination

•Replica set failovers take 5 to 15 seconds during which writes fail and reads may pause, applications must implement retry logic with exponential backoff and idempotency tokens to handle transient unavailability

•Replication lag monitoring is essential: if secondary falls 10 seconds behind during spike, reads from that secondary serve stale data, violating read-after-write expectations for users

•Read preferences balance load and latency: reading from nearest secondary reduces primary load and cross-region latency but risks stale reads, use majority read concern for critical consistency guarantees

📌 Examples

MongoDB write with majority concern: db.orders.insertOne({ orderId: "O123", amount: 500 }, { writeConcern: { w: "majority", wtimeout: 5000 } }) waits for 2 of 3 replicas to acknowledge before returning

Firestore multi-region write: regional write completes in 10ms, multi-region write to nam5 (cross US regions) completes in 50ms due to synchronous replication, trade 40ms for global consistency

Uber booking system uses majority write concern for ride creation (cannot lose a booking) but w:1 for driver location updates (temporary loss acceptable, next update overwrites)

Replica lag scenario: primary handles 50K writes/sec, secondary replication falls 10 seconds behind, user writes to primary then reads from secondary sees old data for 10 seconds until lag catches up

← Back to Document Databases (MongoDB, Firestore) Overview