Reconstruct the actual dependency chain
Suppose checkout performs a lookup for inventory, then fetches an item row, then checks a reservation, then requests a discount adjustment and so on. It's tempting to say the code makes twelve queries, but the important detail is where those queries run. If a backend in region A opens a database connection directly to region B and makes twelve serial calls, each response must cross the inter-region path before the next call begins.
A single prepared statement or stored procedure executed on the database side might combine some operations. A domain API placed beside the data can run a local transaction that does its work within region B and return one coherent outcome to region A. The remote client still makes a request and receives a response, so one WAN round trip remains. We have changed the number of dependent WAN interactions, not made the remote region physically closer.
Now check correctness. If several inventory decisions must be atomic, moving the logic behind a coarse-grained API can preserve one authoritative transactional boundary. Blindly issuing twelve calls in parallel would be wrong when later operations depend on earlier results or when ordering matters to stock reservation. If calls are truly independent, controlled parallelism can reduce the critical path to approximately the slowest branch plus overhead, but that is an application property to prove, not an optimization the network can guess.
A proxy only helps when it changes the boundary
Someone suggests adding a proxy. Where should it run? A proxy next to the caller that relays the same twelve serial commands still pays the wide-area latency twelve times. It may provide connection pooling, authentication and retries, but it doesn't eliminate the underlying dependency chain.
A proxy or execution service co-located with the database can accept one coarse operation over the WAN, execute the twelve short exchanges locally, and return a compact result. That improves the architecture if the protocol supports batching and the execution semantics are safe. But if the proxy merely tunnels one request at a time and waits for another instruction from region A, nothing fundamental changes. The location and responsibility of the proxy matter more than its product name.
Reuse TLS and TCP connections to avoid unnecessary handshakes. Avoid repeated DNS resolution when connection pooling is safe. Compression may help very large payloads. Those optimizations are valuable, but they remove setup costs or bytes, not sequential WAN round trips. An answer that confuses them should be challenged in the interview.
What if the business wants regional independence?
The product team then adds a requirement: checkout in region A should continue if region B becomes unreachable for ten minutes. That changes the problem from pure latency to ownership and consistency. If region B alone owns authoritative inventory reservations, a network partition removes A's ability to guarantee new reservations without either an alternate authority or a predefined allocation of stock.
One option is to keep some inventory authority local through explicit per-region allocation. Another is to accept a pending order and complete reservation asynchronously when connectivity returns. Those choices change user experience and business invariants. We cannot simply cache the remote inventory number and continue decrementing it independently while claiming global no-oversell guarantees. Replicated snapshots can answer product browsing faster, but reservation correctness needs a separate protocol.
This lesson therefore ends with a design choice rather than a latency tweak. Which operations require strong, authoritative answers right now, and which can tolerate a queued or stale outcome? Read-only catalog details could use region-local materialized views. A stock reservation might remain a synchronous call to its owner, or the business may prefer pending confirmation. Group remote operations at the service boundary that understands the invariants.
Measure the new design honestly
I would annotate a distributed trace with number of cross-region request legs, observed path RTT, connection reuse, remote CPU time and queueing. Compare the old twelve-exchange design with one coarse reservation call, using the same workload and error budget. Capture the p95 and p99, not only a fast median. Then cut the inter-region path to see whether the failure contract matches what the product promised.
A successful redesign reduces the number of dependent round trips without weakening ordering, authorization or data correctness. More bandwidth cannot rescue a conversational protocol that asks a distant server twelve dependent questions. Fewer WAN conversations, clear ownership and explicit degraded behavior can.
