Module 14 · Lesson 2 of 8Free

Multi-region architecture: serving users globally

Level

Advanced

Topic

Multi-region systems and disaster recovery

Reading time

19 min

The nearby server still waits

A customer opens Kartly from Europe. The page makes three database calls to Region A in Asia, each paying an assumed 180 ms network round trip.

The team adds an application server in Europe. The page still waits for the same distant database.

How can Kartly serve users near them without giving different regions conflicting versions of an order?

Kartly is at its many-services stage: catalog, cart, orders, payments and search have separate responsibilities. This lesson follows the catalog and order paths, not every service.

All traffic splits, timings and capacities below are illustrative assumptions for this lesson.

The useful unit of placement is therefore a request’s dependency path, not an application server. We need to decide which parts of that path can move together.

Place dependencies near the work

A region is a geographic deployment area. A failure domain is a set of components that one event can disrupt together.

Putting servers in separate zones addresses some failures within a region. A multi-region architecture also places application capacity and data in separate regions. Google Cloud’s deployment archetype illustrates independent regional application stacks with replicated databases.^{1Google Cloud multi-regional deployment archetypeGoogle Cloud, Cloud Architecture Center}

Before adding another region, ask what it must achieve:

These answers do not imply one architecture for every endpoint.

Product images already belong near users through CDNs. An order confirmation has different needs: it must reflect the order that was actually accepted.

The first boundary is between data that may be stale and operations that decide business outcomes. That boundary determines what the second region may do.

Two active apps, one write authority

The simplest correct starting point remains one serving region. It avoids cross-region coordination, but distant users pay network latency and a regional outage interrupts service.

We will add Region B in Europe. The central question is not whether B runs application servers. It is whether B can independently change the same business data.

“Active-active” is incomplete unless you name what is active. Here, application serving is active in both regions. A given order shard still has only one writer.

Give every component a boundary

This diagram shows one shard’s path. Production routing repeats the same authority rule across Kartly’s existing shards.

An independently reachable application is not an independent service if every request still calls A.

For this design, browsing must not synchronously contact A for authentication, pricing or configuration. Any dependency left there keeps A on that request’s failure path.

Follow reads and writes separately

Architecture becomes concrete when you can trace one request without guessing.

A catalog read stays local

1. The customer connects to the global ingress.
2. The ingress selects B because it is eligible and has a better measured network path.
3. B’s catalog service reads its local copy.
4. B returns the product description and a displayed price.
5. Checkout later validates the current price and stock at the authority.

The displayed price is information, not permission to purchase at that price. If validation finds a change, the customer confirms the new price before the purchase proceeds.

A checkout crosses regions

1. B receives the checkout request with a idempotency key.
2. B forwards it to the order authority in A.
3. The authority validates the request against its authoritative state and runs the existing order workflow.
4. It persists the accepted order and retry record before returning success.
5. B relays that result to the customer.

B does not turn a timeout into a new order attempt. The client retains the same key, and retries reach the same logical authority.

The immediate confirmation comes from that authoritative result. A later local replica read might not contain the new order yet; read-your-writes consistency covers that separate read-routing requirement.

Copying later changes the guarantee

For a concrete implementation, PostgreSQL 18 streaming replication is asynchronous by default. The primary can commit before changes become visible on a standby.^{226.2. Log-Shipping Standby ServersPostgreSQL Global Development Group, PostgreSQL 18 Documentation}

That behavior suits our permitted catalog staleness. It does not make B an up-to-date order authority.

PostgreSQL also supports synchronous replication. Depending on configuration, a commit can wait for a standby to durably receive changes or apply them.^{226.2. Log-Shipping Standby ServersPostgreSQL Global Development Group, PostgreSQL 18 Documentation}

Waiting for B adds a cross-region dependency to acknowledgement. Avoiding that wait leaves a possible gap between acknowledged data in A and data available in B.

We have chosen where requests run. Next we need to verify whether those paths actually meet the latency goal.

Count the regional round trips

Assume a 30 ms round trip between the European customer and B. Assume 10 ms of total local database and application work.

These estimates ignore connection setup and queueing to isolate data placement.

The checkout boundary matters. B sends one operation to A instead of making several remote database calls itself.

If three reads are independent, running them concurrently may reduce their elapsed network wait toward one round trip. It does not remove the distant dependency or its failure risk.

For this scenario, local browsing is worth deploying B. Local checkout is not yet worth changing data ownership. That leaves request selection as the next decision.

Route by eligibility before latency

The closest region is not always usable. B might answer HTTP requests while its catalog copy has stopped advancing.

Define eligibility per operation before selecting the fastest region.

Route 53’s documentation explains that external DNS resolvers cache answers according to their time to live. DNS failover therefore does not immediately change every client’s destination.^{3Amazon Route 53 FAQsAmazon Web Services}

Make eligibility explicit

The ingress owns regional serving eligibility. Order services own the shard-to-authority mapping.

For this lesson, assume catalog eligibility requires a verified replication heartbeat no older than 30 seconds. Missing evidence makes the region ineligible.

That threshold is a product choice, not a universal value. A stale description is different from a stale emergency notice.

A process-alive probe cannot establish these conditions. The system needs dependency checks and representative customer-path probes. Eligibility must also allow an operator to remove a region deliberately.

Changing traffic is now precise. It still cannot repair missing write authority or missing capacity.

A region disappears, capacity does not

Assume Kartly’s festival peak is 100,000 requests per second. For this exercise, nearly all are browsing requests.

A normally receives 60,000 requests per second. B receives the rest.

Suppose each region has been load-tested to sustain 70,000 requests per second at the required latency.

For two equally loaded regions, each must normally use no more than half its sustainable capacity to absorb the full combined load immediately.

That statement assumes unchanged request cost and no degraded features. Cold caches or heavier recovery queries can require more capacity.

Autoscaling helps after capacity becomes available. It does not guarantee spare quota, database throughput or fast startup.

Kartly can reserve sufficient browsing capacity, shed optional work, or explicitly accept partial service during failure. Our scenario chooses reduced browsing when full capacity is unavailable.

Refuse checkout without authority

If A becomes unreachable, B may continue eligible catalog reads. Checkout returns a temporary error rather than writing to its replica.

This costs sales, but it respects the product decision against competing stock allocations.

A timeout cannot tell B whether A is dead or merely isolated. Before another store accepts writes, the old authority must be prevented from continuing.

That is a separate recovery operation, covered in Regional failover. A traffic switch alone is not that operation.

Exercise the whole dependency path

A regional exercise should prove a customer outcome, not just a routing change.

Keep deployment artifacts, configuration and required credentials available outside A. Otherwise B may serve existing traffic but fail to replace a crashed instance.

Also exercise login, order lookup and payment access. A healthy catalog response does not prove that a customer can complete a purchase.

The remaining question is operational: does the recovery path still work after months of application and configuration changes? Regular exercises are how Kartly finds that answer.

Common mistakes

• Moving applications without their data path. Measure sequential remote calls before expecting lower latency.
• Calling the whole system active-active. State separately where applications serve and where each shard accepts writes.
• Treating a healthy process as a healthy operation. Test the dependencies needed for the advertised behavior.
• Routing writes to whichever region responds. Reachability is not write authority.
• Counting combined capacity only. Check the surviving region under the actual failure workload.
• Testing only browsing. A regional storefront can work while checkout remains unavailable.

Where this shows up

• Design: an e-commerce checkout: stock authority and safe retries must survive regional routing.
• Design: a distributed key-value store: replica placement determines which operations remain possible during isolation.

Kartly can now place requests deliberately; Geo-replication next examines how the second region receives and catches up with its data.

Check your understanding

Summary