What's changed: Created DP-420 Chapter 3 (Domains 2+3: replication & consistency (five levels strong/bounded staleness/session/consistent prefix/eventual; freshness vs RU/latency), automatic/manual failover, multi-region writes, conflict resolution (LWW/custom); analytical integration (analytical store/Azure Synapse Link HTAP/Microsoft Fabric mirroring vs Spark connector/CDC/Change Feed + Azure Functions denormalize-referential-aggregate-archive/Event Hubs/Azure AI Search)).
3.1Replication, consistency, and multi-region writes
Understand Azure Cosmos DB replication strategy, the five consistency levels, automatic/manual failover, multi-region writes, and custom conflict resolution.
Cosmos DB can be globally distributed across regions. While it boosts availability and latency, you design the trade-off between consistency (how fresh reads are) and RU cost/performance.
3.1.1The five consistency levels
Five levels, strongest first: strong (always reads the latest, but max latency/RU; not usable with multi-region writes), bounded staleness (tolerate at most K operations or T time of lag), session (read your own writes within a session; the well-balanced default), consistent prefix (guarantees order but not the latest), eventual (weakest, fastest, cheapest). Choose by requirement (freshness vs latency/cost); the SDK can override per query only toward weaker.
3.1.2Failover and multi-region writes
In a single-write-region setup, an automatic failover policy moves the write region to another region on regional failure (by priority). Planned moves use manual failover. Enabling multi-region writes lets you write in all regions (low latency, high availability), but the same item updated concurrently in different regions causes a conflict. Resolve conflicts via Last Write Wins (LWW; default / max of a chosen property) or a custom conflict-resolution stored procedure. For "write in all regions," use multi-region writes + a conflict-resolution design.
Cues: "always latest" = strong (max latency/RU; no MRW). "lag up to K ops/T time" = bounded staleness. "read your own writes; default" = session. "order only" = consistent prefix. "fastest/cheapest" = eventual. "write in all regions" = multi-region writes + conflict resolution (LWW/custom). auto-move on failure = automatic failover.
Watch the mix-ups: (1) Strong cannot be used with multi-region writes. (2) Consistency overrides only toward weaker (cannot exceed the account setting). (3) Multi-region writes require a conflict-resolution policy. (4) Automatic failover (on failure) vs manual failover (planned move).
3.1.3Section summary
- Five levels = strong/bounded staleness/session (default)/consistent prefix/eventual—freshness vs RU/latency trade-off
- Automatic failover (on failure) / manual failover (planned) move the write region
- Multi-region writes = write everywhere; conflict resolution (LWW/custom stored procedure) is required
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You require reads to always reflect the latest write (accepting higher latency/RU). Best consistency level?
Q2. You just need to read your own writes within a session and want the well-balanced default. Best level?
Q3. You tolerate lag up to K operations or T time while keeping strong-ish consistency. Best level?
Q4. You want low-latency writes in all regions. Best (also needs conflict-resolution design)?
Q5. In multi-region writes, you want to resolve a conflict (same item updated concurrently in different regions) with the default method. Best?

