Designing to a Latency Budget
Definition
A latency budget is a response time treated as a requirement rather than a goal. When the budget is tight enough, it stops being a performance target and starts dictating architecture: it removes options rather than ranking them.
Suica, JR East’s contactless transit card launched November 2001, is the clean case. The budget was under 200 milliseconds per tap, set by the throughput of Tokyo’s station gates at rush hour. That single number decided the data model.
Core Ideas
The budget chooses the architecture
Each card stores two things on the card itself: a unique card ID and the current balance. A tap reads and rewrites the card locally, with mutual authentication between card and terminal and a fresh encryption key generated per transaction to prevent spoofing. The card has no battery — the gate’s electromagnetic field powers it for exactly as long as the transaction takes.
Why not check a central server? Because the round trip does not fit in the budget, and because of what a shared dependency means at that volume:
Transactions would take longer, causing people to slow down at already-crowded gates. And any network issues — latency, packet loss, server downtime — would cause the gates to shut down, which would be disastrous during peak commuting hours.
Gates do sync to central servers, but periodically, for transaction logs — never on the critical path. The correctness model moves with it: the card is authoritative for balance, and the servers are a downstream record.
The failure was in the interface, not the technology
This is the part worth keeping. When the readers were first tested, the error rate was worse than the magnetic tickets they were replacing. Nearly half the testers could not get through the gates; one executive reported it working “once every five tries — a 20% batting average.” Leadership was ready to kill the project.
The technology was fine. People were using it wrong, and the design was why: the readers were completely flat and signalled nothing about what to do, so users treated them like barcode scanners — swiping too fast, or holding the card too high to stay in the field.
Adding an explicit “tap here” label did not fix it. After four prototypes tested at a public exhibition and analysis of the footage, the fix was geometric: tilt the reader 13.5 degrees. That angle matches the natural forward motion of a hand, so users instinctively rest the card for a split second — long enough to complete the transaction — and the reader is visible from further away. Error rate fell below 1%. The design was patented and is still the standard for IC card readers.
The generalisable point: when adoption fails at the last inch, measure whether the system or the human is missing the budget, because the fixes live in different places. Instrumentation that only watches the software would have shown a working system with unhappy users.
Launching a system with no soft launch
Suica had no public beta. Employee trials and controlled passenger trials, then 3,200 gates across 424 stations went live at once, on 18 November 2001 — after slipping from a symbolic 1 January 2001 target. Within 19 days a million cards were issued, two million in two months, five million by October 2002.
One constraint explains an odd detail: JR East manufactured and warehoused cards ahead of launch but did not pre-issue them, because activation happens at purchase and requires the live network. Even the stockpile could not be prepared ahead of the system existing.
The card then grew past its original scope — other rail lines in 2002, general e-money in 2004 — which is what a card that holds its own balance makes cheap.
Twenty-five years on, the 200ms response is still fast by current standards, and Suica remains among the fastest transit cards in the world.
Relationships
- System Design — where a hard budget sits among the other design constraints
- Observability — measuring the human side of the transaction, not just the software side
- UI Design Principles — the 13.5-degree fix as hierarchy and affordance beating instruction text
- Web Rendering and Performance Patterns — the same reasoning applied to a page’s first paint
- Self-Hosted Infrastructure — removing a network dependency because it is a failure domain
- Software Architecture & Distributed Systems — parent topic
References
- The Story of Suica, Japan’s First IC Transit Card