Admission Token Mint

A rate limit of 100 requests per minute per user, enforced independently in 40 locations, permits 4,000. The same arithmetic ruins every attempt to hold a queue, a seat allocation or a purchase quota at the edge: anything that must be globally exact is a single counter, and the edge is many copies of everything.

The pattern splits the problem along that line. One central component mints tokens at the rate the scarce resource can absorb; every edge location verifies a signature and spends the token. Minting is a single-writer operation on a counter. Verification is a public-key check that needs no shared state, so it is correct simultaneously in 300 places and costs microseconds. The central mint handles a trickle of issuance while the edge absorbs the flood.

Why it matters

Peak events concentrate load on the one component whose correctness cannot be approximated. Ticketmaster's November 2022 statement on the Eras Tour onsale reports about 3.5 billion system requests, roughly four times its previous peak, and bots going after its Verified Fan access-code servers for the first time in 400 such onsales. The entitlement check is both the correctness-bearing component and the attack target, and scaling it against a 4x surge is a losing race.

Pre-minting changes the shape: entitlement is computed before the event, handed to the client as a signed expiring ticket, and the hot path verifies rather than looks up. The component that was the bottleneck is no longer on the critical path.

Implementation patterns

• Mint ahead of time where the entitlement is knowable - registration closes, codes are bound to identities, tokens are issued. The onsale second then contains no database read for admission.
• Short lifetimes and narrow scope. A token names one user, one event, one action, and expires in minutes. The lifetime is your revocation window, so state it as a number rather than discovering it.
• Asymmetric signatures. Edge locations hold only the public key, so a compromised location cannot mint. This is the property that makes the pattern safe to distribute widely.
• One-time spend where exactness matters. Verification alone does not stop replay, so a token that must be used once needs a central or regional spend record - keep that at the purchase step, not at the queue step, so the exactness cost is paid once per sale rather than once per poll.
• Drip release. The mint emits tokens at the rate downstream can absorb, making the queue a throughput control rather than a waiting list.
• A key rotation plan with overlapping validity, because every location must accept both keys during the change and rotating during a peak event is how this pattern fails.
• Say what the approximation budget is. If admitting 4,100 against 4,000 slots is acceptable, much more can live at the edge; if it must be exact, the spend record is central.

Industry example

Signed-URL and signed-cookie schemes offered by every major CDN are this pattern in its simplest form: an origin mints a capability, edge nodes verify it without consulting the origin, and expiry bounds the damage. Waiting-room products sold by edge providers use the same split - the edge serves the holding page and admits holders of a token the central service issued.

The same instinct appears wherever demand is scheduled rather than organic. A shopping festival with a countdown, or an onsale with a published time, rewards moving every decision that can be made in advance out of the critical second: entitlement bound beforehand, capacity in place beforehand, and a hot path that verifies rather than computes.

Failure scenarios

• Per-location enforcement mistaken for a global limit. The 40-locations-times-100 case above. It is discovered by an abuse report, not by a test.
• Queue position in replicated edge storage. Replication lag makes positions non-monotonic, users compare screenshots, and the support cost exceeds the engineering saving.
• Token lifetime too long. A ticket valid for an hour is a transferable asset; it will be sold, scripted and shared, and your revocation window is an hour.
• Clock skew at the edge. Expiry checks fail open or closed inconsistently across locations. Validate against a signed issue time with a tolerance, and monitor location clock offset.
• Mint outage during the event. Admission stops entirely. Pre-mint a buffer, and define what the edge does when the mint is unreachable - admit nobody is usually correct here, and it must be a decision rather than an accident.

Trade-offs

When not to use it

If the budget does not have to be exact, skip the mint. Abuse throttling, bot friction and fair-share smoothing work well as approximate per-location limits, and adding a signing infrastructure buys precision nobody needed. Skip it too when the event is small enough that a central queue can serve every request directly: a few thousand requests per second against one regional service is cheaper to build, reason about and debug than a token system with key rotation.

And when the inventory is genuinely tiny - a 500-seat show - the whole machine is the wrong answer. A registration window that closes, a lottery, and emailed purchase links remove the critical second entirely, at the cost of the live-sale experience the business may be deliberately selling.

Interview question

Q: Design the admission flow for an onsale expected to draw 50 times normal traffic for one minute. What runs at the edge, what stays central, and what do you tell the business about fairness?

What a strong answer covers: the per-location multiplication that rules out edge-held budgets; central mint and edge verification with asymmetric keys; pre-binding entitlement before the event so the hot path verifies instead of reading; short scoped lifetimes as the stated revocation window; where the one-time spend record lives and why it sits at purchase rather than at poll; drip release as a throughput control tied to the purchase path's capacity; key rotation with overlap; and the business conversation that admission rate is a fairness-versus-throughput decision, with a lottery as the honest alternative for tiny inventories.

Quick check

Quiz: Why can a 100-per-minute limit enforced at 40 edge locations not be called a limit? Because each location keeps its own counter, so the effective limit is 4,000 per minute - approximate limits suit abuse control and never entitlement.

Flashcard: What is the split that lets a scarce entitlement scale to the edge? The centre mints signed expiring tokens at the rate the resource can absorb; every location verifies the signature with a public key and holds no state - so exactness lives in one writer and verification lives everywhere.