Mocking Region-Specific Latency for Slow-Network Clients

Quick answer: Latency changes by region, so a client that only passes on your local network may time out or feel broken for a distant user. Mock it by matching each request to a region and returning a fixed delay for that region, rather than setting one global delay. This gives you deterministic slow, near, and extreme cases so you can verify loading states, timeout handling, and backoff without traveling or depending on an unstable real network.

Why one global delay is not enough

Setting a single delay on the mock tells you the client survives one slow call, but it does not model the real spread. A user near the data center sees a short round trip, a user on another continent waits much longer, and a congested region can push the call past the client's timeout. Those paths need different delays, and a single number cannot reproduce the contrast. Real cross-region requests are also hard to drive and inconsistent run to run, so a test that depends on them is both inconvenient and flaky. Tie the delay to a region marker in the request, such as a header, subdomain, or environment value, so each region is a distinct, repeatable branch.

Inject latency per region

Use conditional response overrides that match the region and apply a fixed delay, keeping the values inside the supported range and covering the points below.

The high-latency row is the one that exposes a bad timeout. If the client fires several retries the moment the wait grows, it creates a burst instead of waiting, which the mock makes obvious.

What to assert on the client

On a slow but successful call, confirm the loading state shows and stays, and that exactly one request is in flight rather than a stack of retries. When the delay crosses the timeout, assert the timeout path runs, the client backs off before retrying, and the UI does not flicker or silently drop the response that arrives late. Compare the near and distant branches in the same run so the timeout threshold is judged against realistic delays rather than a guess. Inspect the recorded requests and their timing to confirm the delay the mock applied and the retry spacing. A desktop API workspace lets you set these conditional delays, inspect the recorded timing, and assert on the responses in one place. Powerduck works this way, with delays configured per override so each region is a fixed scenario.

Honest limits

A local mock runs in the desktop main process, and the delay it adds is artificial and fixed. It reproduces waiting time, not the full shape of a bad network: it does not model jitter, packet loss, bandwidth limits, TLS handshake cost, or real cross-region routing, and the timing precision is subject to local process scheduling. A fixed delay therefore cannot stand in for measured network quality. Confirm the real regional spread and the live timeout behavior with a small set of genuine cross-region requests or monitoring data. Importing a schema does not deploy a backend, and a passing mock run is not evidence about the production network.

Frequently asked questions

Is a fixed mock delay the same as a slow real network? No. It reproduces a wait so you can test timeout and loading logic, but it does not model jitter, packet loss, or bandwidth. Confirm those against real traffic.

Why not just set one global delay? Because regions have different delays and the client behaves differently below and above its timeout. Per-region overrides reproduce that spread in one repeatable test.

What should happen when the delay exceeds the timeout? The client should time out, back off, and retry on a schedule rather than firing many immediate requests. The high-latency row verifies exactly that.

How do I choose a realistic timeout? Base it on the real regional latency distribution, not a local round trip. Use the mock to test near and distant values, then confirm the threshold against live measurements.

The bottom line

Model latency by region with conditional delays, not one global number, because the failure appears only when the wait crosses the client's timeout. Cover the near, distant, extreme, and intermittent cases, assert single in-flight requests and backoff rather than retry bursts, and verify the real network spread separately. For more on this approach, see the API mocking guide hub.