Instiq
Chapter 3 · Data distribution and integration·v1.0.0·Updated 6/28/2026·~15 min

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

Key points

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.

Exam point

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.

Warning

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).

Diagram of five consistency levels (strong latest/bounded staleness K-ops-T-time/session default/consistent prefix order/eventual fastest), automatic/manual failover, multi-region writes with conflict resolution (LWW/custom), and the freshness vs RU/latency trade-off.
Freshness vs cost

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?

Check your understandingPractice questions for Chapter 3: Data distribution and integration