A courier fleet of 8000 phones sends one location update every 5 seconds while on shift, 8 hours a day. Each update is about 400 bytes on the wire including headers on a reused connection. Roughly how much cellular data is that per device per month?

The arithmetic

updates per shift   = 8 h × 3600 / 5 s        = 5760
bytes per shift     = 5760 × 400 B            ≈ 2.3 MB
per month (30 days) ≈ 69 MB per device
fleet               = 8000 × 69 MB            ≈ 550 GB per month

Why the other options fail

• 7 MB. An order of magnitude out, which usually comes from using the payload size and forgetting that TLS records, TCP/IP headers and the HTTP framing roughly double a 200-byte body.
• 700 MB. This is what you get with a 2 KB payload, or with a new TLS handshake per update instead of a reused connection. Both are common in practice, which is why the number is worth computing rather than assuming — a design that reconnects per update costs several times the bytes and far more battery.
• 2 GB. Video scale. If a telemetry estimate lands here, an assumption is wrong by a factor of thirty.

Which assumption dominates the error

Shift hours and per-update overhead, in that order. Doubling the shift doubles the answer; halving the overhead by batching does not change the payload bytes at all. Everything else — compression, protocol choice, sampling jitter — moves the result by less than a factor of two.

What the number rules in and out

70 MB a month is unremarkable on a bundled plan, so cellular data is not the constraint here. The constraint is battery, and the same arithmetic tells you why: 5760 radio wakes per shift, each carrying a tail of elevated power after the transmission, is the dominant drain on a device someone must carry for eight hours.

That points at the fix. Prefer twelve updates batched into one post per minute: identical payload bytes, a twelfth of the header and handshake overhead, and roughly a twelfth of the radio wakes, because on a cellular radio the cost of a transmission is dominated by waking the radio rather than by the bytes sent. The cost is up to sixty seconds of staleness in the operations view, which is a product decision rather than an engineering one, and it is usually accepted immediately once someone sees the battery numbers.

The physical-world constraints this misses

Couriers lose coverage in lifts, basements and rural gaps, so the client needs a bounded buffer — an hour of buffering is around 700 updates, which is trivial storage — with a policy for what to drop when it fills, and backfill marked as low priority so it never competes with live positions. And some of those phones are personal devices on metered plans, which makes 70 MB a conversation with a union rather than a rounding error.

Common weak answers

• "Compress the payload." A 200-byte JSON body compresses badly and the win is a fraction of the header overhead you could have removed by batching.
• "Switch to a binary protocol." Worth doing eventually and it is a factor of two, where batching is a factor of twelve. Order the work by effect size.
• "Sample less often." It is the right lever when the product can accept it, and it is a product decision about how stale a courier's position may be. Bring it as a choice with a number, not as an engineering preference.