Moving a working app from one region to many looks simple on a whiteboard and becomes a list of footnotes in production. Ours started with one SQL Server, one cache, and one search cluster, plus customers in other regions feeling the latency.

Central writes, regional reads

We kept one write authority. All writes go to the central database. Reads, which dominate an e-commerce workload, fan out to regional replicas.

  • SQL Server transactional replication keeps regional read replicas in sync.
  • Read replicas serve product and content reads close to the user.
  • Cross-region cache invalidation stops a price change in Singapore from leaving a stale price in Europe.

The parts that actually hurt

The hard problems were not the glamorous ones:

  • Replication lag. A write committed centrally is not instantly visible regionally. We decided what tolerates lag (product descriptions) and what does not (prices, inventory).
  • Cache invalidation across regions. The obvious “invalidate everywhere” approach doubles network chatter, so we used a distributed cache with multi-layer invalidation.
  • Idempotency. An asynchronous order queue with outbox and inbox patterns, so a retry never double-processes an order.

What I’d do differently

Build the outbox/inbox discipline from day one instead of retrofitting it. Almost every multi-region headache (replays, retries, lag, partial failures) gets simpler once you accept that messages are the system of record and the database is just where they land.