Cosmos DB Multi-Region Writes: Strong Consistency or Bust?
Multi-region writes give you global low latency — but the consistency level you pick changes everything about what your app sees.
Azure Cosmos DB lets you write to multiple regions simultaneously. That single setting changes the read/write characteristics of your entire app, and it interacts with the consistency level in ways most teams underestimate.
The five consistency levels
- Strong — reads always see the latest commit. Cannot be combined with multi-region writes; only single-region.
- Bounded staleness — reads can lag by N writes or T seconds. Strong consistency within the window.
- Session (default) — a single client session sees its own writes; other sessions may lag.
- Consistent prefix — reads never see out-of-order writes (you'll see A then B, not B then A).
- Eventual — cheapest, fastest, no order guarantees.
The trade-off
Multi-region writes require you to use Bounded Staleness or weaker. That means a write in Sweden Central is visible in Korea Central after a bounded delay — not instantly. Your app needs to tolerate this.
Conflict resolution: who wins?
When two regions write the same document at the same time:
- Last-write-wins on a numeric/timestamp property (default).
- Custom merge stored procedure — you write JS that merges the two versions.
- Conflict feed — conflicts go to a separate stream you read async.
Pattern: per-tenant home region
The cleanest design for SaaS: each tenant has a home region. Writes go there; other regions are read-only replicas. Conflicts are mathematically impossible because no other region writes the tenant's data. You get global low-latency reads with no merge logic.
This pattern needs only Session consistency and avoids the entire conflict-resolution rabbit hole. It's how most Cosmos at scale actually looks.