Latency you can actually feel

A customer taps "send code", waits, taps again, and gives up before either code arrives. Your API dashboard says the provider answered in 120 milliseconds. Both are true: the part you measure is the smallest part of the wait. Latency in communications comes in two very different kinds — seconds for a message to reach a phone, milliseconds for a live call to feel natural — and in both, the time people feel is mostly decided by routes and design, not by your code. This piece covers where the time goes, what to measure, and how to design for the slow case.

For a one-time code — the most latency-sensitive message most businesses send — the budget looks nothing like people expect:

The API call — the only segment many teams instrument — is often the smallest term. Under load, or when a route is congested, queueing dominates everything else, and the same code can take two seconds in one country and twenty in another.

1. Measure end to end. A timestamp when you decided to send, and one when the delivery receipt arrives. That is the number the customer experiences.
2. Watch the tail, not the average. Nobody experiences the mean. The 95th and 99th percentiles are what a support team hears about; a two-second average routinely hides a tail in the tens of seconds.
3. Split by country and hour. Latency problems are local. A global number hides the market that is broken on Tuesday afternoons.
4. Choose the route. A direct connection to operators in-market typically beats any optimisation above it. This is a purchasing decision that looks like an engineering one.
5. Do the slow work early. Consent state, template approval and route choice should be ready before the send; the send path should not be where a cache miss first shows up.
6. Send before you need to. For anything predictable — a reminder, a scheduled notice — the budget starts when you decide, not when the user waits.

Retry with backoff and a cap, and make retries safe for the recipient. The failure mode is not a slow message; it is four copies of the same code arriving at once, two already invalid.

A retry down the route that just failed is a second attempt at a failure: it adds load to a struggling path and delays the user further. Retry on a different route or channel, or tell the user instead — and stop after a small number of attempts. Systems without a ceiling produce the outage-day pattern where everyone is retrying and nothing gets through.

For calls, the reference point is the ITU-T G.114 recommendation on one-way transmission delay: up to about 150 ms is acceptable for most conversations; between 150 and 400 ms is usable but noticeable; beyond 400 ms is not acceptable for normal conversation planning. In practice:

• Distance matters. Media relayed through a server on another continent can use most of that budget before any processing happens. Ask where media servers are, not only where the company is.
• Jitter and packet loss feel like latency. Buffers that smooth out jitter add delay; lost packets cause gaps. Good networks matter more than raw bandwidth.
• Relays are common. Even "peer-to-peer" WebRTC calls fall back to a relay (TURN) server when a direct path cannot be made, often on corporate or mobile networks.

A fintech app saw complaints about login codes in one country only.

• End-to-end measurement showed a median of 4 seconds there but a 95th percentile of 38 seconds between 6pm and 10pm; other countries stayed under 10 seconds.
• The cause was a partner route with an aggregator hop that congested in the evening.
• Changes: a direct route for that country from a second provider; code validity raised from 60 to 180 seconds; a "send by voice call" option shown at 15 seconds; one resend allowed, on the other route.
• Result: the 95th percentile fell to 9 seconds, and failed logins in that country fell sharply. No line of the code-generation logic changed.

• What are your median and 95th-percentile delivery times per country, measured to the delivery receipt — not to API acceptance?
• Which countries do you reach directly, and which through partners?
• What does a "delivered" receipt mean in each country, and how late can it arrive?
• For voice and video, where are your media and relay servers, and can I choose the region?

Next in this track: when video belongs in support. To put delivery-time commitments into an agreement, read evaluating a CPaaS contract; for how live media works underneath, see WebRTC in plain terms.