Offline transit fare authorization
Design a transit-fare wallet where riders tap at gates that are frequently offline (subway, no connectivity), so a tap must be authorized at the gate in <300ms WITHOUT a round trip to the server, then settled later when the gate reconnects. ~50M cards, peak ~20,000 taps/sec across gates. The hard problem: a rider with a near-zero balance could tap at multiple offline gates and overspend (double-spend). How do you authorize offline yet keep the wallet balance correct and bound the loss?
What a strong answer looks like
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.
Clarify5:00 left
Estimate5:00 planned
Design15:00 planned
Deep dive12:00 planned
Failure8:00 planned
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.
Run or narrate your approach, then ask the coach.