A mobility platform operates across several Southeast Asian markets where mobile networks vary enormously in quality, latency and reliability. Which network-layer decisions matter most, and which common assumption breaks first?

The assumption that breaks first

That a connection, once established, stays usable. On a good fixed network, a TCP connection either works or fails. On congested mobile networks it does neither: it stalls, recovers, loses packets in bursts, and switches between cell towers and between mobile and WiFi mid-session — often without the application noticing that anything happened.

Systems designed with the fixed-network assumption exhibit a characteristic symptom: requests that neither succeed nor fail, holding a connection until some distant timeout fires. The user has already given up and retried twice.

The decisions that matter

1. Aggressive, explicit client-side timeouts. Far shorter than a default. On a network where 30% of requests will be slow, waiting the default is a guarantee of a bad experience. A short timeout plus a retry on a fresh connection is usually faster than waiting for a stalled one.

2. Connection reuse and multiplexing. Handshake cost is brutal on high-latency links — a TCP handshake plus a TLS handshake can be several round trips before a byte of application data moves. On a 300 ms network that is a second before anything happens. Persistent connections and protocols that multiplex multiple streams over one connection are not optimisations here; they are the difference between usable and unusable.

3. Payload size as a first-class constraint. Bandwidth is expensive to the user, not only to the platform. Compact encodings, field selection, and compression matter more than they do in well-connected markets — and this is a product decision as much as a technical one.

4. Idempotency everywhere. With frequent ambiguous failures, clients retry constantly and often cannot tell whether the original request succeeded. Every state-changing operation needs an idempotency key, or duplicate bookings and duplicate charges become routine rather than exceptional.

5. Offline tolerance for the driver application. A driver going through a tunnel or a basement car park must not lose their job assignment. Local queuing of location updates and state changes, with reconciliation on reconnect, is a requirement rather than a nicety.

6. Regional presence to shorten the round trip. No protocol optimisation beats reducing the distance. Serving from within the market removes the largest single contributor to latency.

The specific failure to design against

Location update floods on reconnect. Thousands of drivers emerge from a coverage gap simultaneously after a network event and each flush their queued updates. The platform receives a burst of stale location data that is both useless and expensive.

The design response: clients send only the most recent position rather than the full backlog, batch aggressively, and back off with jitter. Server-side, stale updates are discarded on arrival rather than processed, because a location from four minutes ago has no value in a dispatch decision.

The transferable lesson

Designing for a variable network is not about making the good case faster. It is about making the ambiguous case cheap — short timeouts, idempotent retries, local buffering, and discarding work that has become worthless — because on these networks the ambiguous case is the common case.