The Sub-200ms Tap

It is the third act, the headliner is on, and eighty thousand people all decide they want a drink at once. The line is twenty deep. Every tap that takes a full second to confirm is a person standing still, a bartender waiting, a queue growing behind them. At that scale latency is not a technical nicety. It is throughput, revenue, and whether the crowd has a good night. The tap has to feel instant, and instant means under two hundred milliseconds from tap to confirmation.

The network is the enemy

You cannot hit that number with a round trip to a server. A single request to a payment processor over a congested festival network is a hundred milliseconds on a good day and several seconds on a bad one, and festival networks are always bad: cellular is saturated by eighty thousand phones, Wi-Fi backhaul buckles. So we do not leave the device. Authorization happens locally against on-device state. Each wristband carries a balance, and the reader validates and decrements against a cryptographically signed ledger it already holds. Settlement with the backend happens asynchronously, batched, out of the critical path. The attendee sees a green light in the time it takes to lift their hand.

Precompute everything you can

The fastest work is the work you already did. Before the doors open, keys are provisioned, ledgers are distributed, and the cryptographic material for validation is cached on every reader. During the tap there is nothing to fetch, nothing to derive, nothing to negotiate; the reader verifies a signature against keys it holds and updates a local balance. This is the discipline behind every fast system: move work out of the hot path. A tap is not the moment to check a policy from a server or resolve a customer profile. It is the moment to do the one irreducible thing, verify and decrement, and defer the rest. Caching is not an optimization you sprinkle on later. It is the architecture.

Budget the milliseconds, chase the tail

Two hundred milliseconds sounds generous until you spend it. The NFC field energizes the card and exchanges data, which is fifty to eighty milliseconds you do not control, dictated by the protocol and the antenna. That leaves roughly a hundred for you. Signature verification is ten. Ledger read and write is another ten. UI paint and the confirmation tone are twenty. Every remaining millisecond is contingency for the tail. Write the budget down, measure each stage, and defend it line by line, because the parts you do not measure are exactly the parts that blow it.

A great median is a trap. If your median tap is 120 milliseconds but your p99 is two seconds, then one tap in a hundred stalls, and across eighty thousand attendees tapping all night that is thousands of visible failures. People do not remember the average; they remember the freeze, the awkward second staring at a dead reader. So we measure in the field, not the lab. Every reader timestamps each stage of every tap and ships the histogram back when it reconciles, and we watch the full distribution live, p50 through p999. A garbage-collection pause, a flash write stall, a cold cache on a fresh reader: each shows up as tail latency long before anyone complains.

Users do not feel your median. They feel your worst tap, so engineer the tail and the average takes care of itself.

— Protocore · Payments engineering

We ran this architecture across eighty thousand attendees and cleared 2.4 million euros with a median tap-to-confirm of 120 milliseconds, comfortably under budget, and zero disputes. That number did not come from a faster server. It came from refusing the round trip, precomputing everything, spending the latency budget with discipline, and treating the tail as the thing that actually ships. Make the tap feel instant, and the crowd never thinks about payments at all. That is the whole point.