10,000 logins per second is the number that decides whether your OTT platform survives the moment a host says "voting is now open," and it is the scenario this article is built around. The way you absorb that spike is not by adding database replicas. You absorb it by verifying tokens at the edge with stateless JWTs, caching the signing keys aggressively, and making sure the hot path for a logged-in viewer never touches your identity store at all.

High traffic authentication: the practice of validating who a user is at a request rate far above your steady-state load, by pushing verification to stateless, cacheable layers (edge tokens, signed cookies, cached signing keys) so that a sudden surge in concurrent logins does not become a surge in database reads.

About this article:

• Researched and written: June 2026. Last fact-checked: 2026-06-17.

• Author hands-on experience: partial. Patterns drawn from production experience and reproducible local benchmarks; exact numbers vary by hardware.

• AI assistance: used for drafting, reviewed and edited by the named author.

• Conflicts of interest: MojoAuth, the publisher, sells authentication infrastructure; the patterns in this article are vendor-neutral and apply regardless of provider.

• Sponsorship: none.

Key Takeaways

• A live-event login surge is a read-amplification problem first: every uncached token check that hits your identity database multiplies one request into one query.

• Stateless JWTs let edge nodes verify a viewer's session with a signature check and zero network calls to your auth service once the public key is cached.

• RFC 7517 JWKS endpoints publish your rotating public keys; caching the JWKS by its kid for minutes, not seconds, removes the most common hidden database-adjacent hit.

• Short access-token lifetimes (5 to 15 minutes) plus refresh tokens keep revocation realistic without forcing a database lookup on every play or vote request.

• Connection pooling with PgBouncer and a write-behind cache for the few writes you cannot avoid (vote tallies, audit logs) keep the origin alive when the edge cannot answer.

Why Does a Live Voting Spike Break Normal Authentication?

A live voting spike breaks normal authentication because the traffic shape inverts everything your steady-state architecture optimized for. During a normal hour, logins trickle in and your session store handles them comfortably. When a host announces voting, tens of thousands of viewers tap "vote" in the same five-second window, and every one of those taps needs an authenticated request.

The failure is rarely the login itself. It is the session validation that follows. If each authenticated request validates by reading a session row from a database, then 10,000 requests per second becomes 10,000 database reads per second on top of your existing load. PostgreSQL defaults to a max_connections of 100, and each connection carries real memory and scheduling cost, so you cannot simply open a connection per concurrent request. The connection pool becomes the bottleneck long before raw query throughput does.

This is a read-amplification problem. One viewer action turns into one auth lookup, and the lookup is on the critical path. The fix is to make session validation answerable without talking to the database. That is exactly what a stateless token gives you.

What Makes Stateless JWTs the Right Tool for the Surge?

Stateless JWTs are the right tool because they move the proof of identity into the request itself, signed by your auth server, verifiable by anyone holding the public key. A JWT carries its claims (subject, expiry, scopes) in the payload and a signature over them. To trust it, a service checks the signature and the expiry. Neither check requires a database.

Use asymmetric signing (RS256 or ES256), not a shared secret (HS256). With asymmetric keys, your auth server holds the private key and signs tokens, while every edge node and API service holds only the public key and verifies. You can distribute the public key to thousands of edge locations without ever exposing the signing secret. The public keys are published at a JWKS endpoint per RFC 7517, each key tagged with a kid (key ID) so verifiers can pick the right one during rotation.

Here is a Cloudflare Worker that verifies an RS256 token at the edge using the built-in Web Crypto API, with the JWKS cached so the hot path makes zero network calls:

// Edge JWT verification. JWKS is fetched once, then served from cache.
const JWKS_URL = "https://auth.example.com/.well-known/jwks.json";
const JWKS_TTL_MS = 10 * 60 * 1000; // cache keys for 10 minutes
let jwksCache = { keys: new Map(), fetchedAt: 0 };

async function getKey(kid) {
  if (Date.now() - jwksCache.fetchedAt > JWKS_TTL_MS) {
    const res = await fetch(JWKS_URL, { cf: { cacheTtl: 600 } });
    const { keys } = await res.json();
    jwksCache.keys = new Map(keys.map(k => [k.kid, k]));
    jwksCache.fetchedAt = Date.now();
  }
  return jwksCache.keys.get(kid);
}

async function verify(token) {
  const [headerB64, payloadB64, sigB64] = token.split(".");
  const header = JSON.parse(atob(headerB64));
  const jwk = await getKey(header.kid);
  if (!jwk) return null;

  const key = await crypto.subtle.importKey(
    "jwk", jwk,
    { name: "RSASSA-PKCS1-v1_5", hash: "SHA-256" },
    false, ["verify"]
  );
  const data = new TextEncoder().encode(`${headerB64}.${payloadB64}`);
  const sig = Uint8Array.from(atob(sigB64.replace(/-/g, "+").replace(/_/g, "/")), c => c.charCodeAt(0));
  const ok = await crypto.subtle.verify("RSASSA-PKCS1-v1_5", key, sig, data);
  if (!ok) return null;

  const payload = JSON.parse(atob(payloadB64));
  if (payload.exp * 1000 < Date.now()) return null; // expired
  return payload;
}

The first request fetches the JWKS. Every request after that, for the next ten minutes, verifies locally. At 10,000 requests per second, that is 10,000 signature checks and zero auth-server round trips. A signature verification is microseconds of CPU; a database round trip is milliseconds plus connection contention. That gap is the entire game.

How Do You Verify Tokens at the Edge Without Hitting the Database?

You verify at the edge by giving every edge node the public key and the verification logic, so the decision is local. The viewer's browser sends the access token (in an Authorization header or a cookie) with each request. The edge node checks the signature against its cached JWKS, checks exp, checks the audience claim, and either passes the request to origin or rejects it, all without a network hop to your auth service.

The audience claim matters more than people expect under load. A token minted for your mobile app should not be accepted by your voting API unless the voting API is in its aud. Validating the audience claim at the edge stops token-reuse abuse from amplifying into origin traffic during the spike, because rejected requests never reach your servers.

The cache key for JWKS is the kid, not the URL. When you rotate signing keys, the new tokens carry a new kid, the edge sees a cache miss for that one key, fetches the updated JWKS once, and resumes local verification. Old tokens signed with the previous key keep verifying until they expire. Set the JWKS cache TTL in minutes. A one-second TTL turns your JWKS endpoint into a thundering-herd target during the exact moment you cannot afford one. The Cloudflare cache and the in-isolate map in the code above give you two layers: the isolate-local map answers most requests, and the cf: { cacheTtl: 600 } hint keeps the colo-level cache warm.

What Should the Origin Still Handle, and How Do You Protect It?

The origin still handles the things a token cannot answer: minting tokens at login, refreshing them, recording votes, and revoking sessions. These are a small fraction of total requests, but they are the writes, and writes do not cache. Your job is to keep that fraction small and protected.

Keep access tokens short, 5 to 15 minutes, and pair them with longer-lived refresh tokens. Short access tokens make stateless revocation tolerable: a banned account stops working within one token lifetime without you maintaining a per-request blocklist lookup. The login and refresh endpoints are where the database lives, so put a connection pooler in front of it. PgBouncer in transaction mode lets thousands of client connections share a small pool of real PostgreSQL backends:

[databases]
auth = host=10.0.0.5 port=5432 dbname=auth

[pgbouncer]
pool_mode = transaction
max_client_conn = 10000
default_pool_size = 25
reserve_pool_size = 5

With pool_mode = transaction and a default_pool_size of 25, ten thousand inbound client connections multiplex onto 25 real backends. The viewers waiting to log in queue at the pooler instead of exhausting PostgreSQL's max_connections. For the writes you genuinely cannot avoid, like incrementing a vote tally, use a write-behind pattern: accept the vote into a fast in-memory counter, acknowledge the viewer immediately, and flush aggregated counts to the database on an interval. The Redis docs cover the patterns for this; the key idea is that the viewer's acknowledgment does not block on a durable write.

A managed passwordless platform such as MojoAuth handles JWKS rotation and edge token verification for you, which removes a class of operational mistakes (forgetting to cache the JWKS, rotating keys without a kid) that tend to surface only under peak load. Whether you build or buy, the architecture is the same: stateless tokens out front, a small protected write path behind.

How Do You Load Test the 10,000-Per-Second Path Before the Event?

You load test it by replaying the real request shape, a burst of authenticated requests carrying valid tokens, against a staging stack that mirrors production. Synthetic tests that only hammer the login endpoint miss the point, because the surge is mostly already-authenticated traffic checking tokens. Generate a batch of valid tokens first, then fire them.

k6 is a good fit because it models ramping arrival rates rather than fixed virtual users, which matches the "voting just opened" shape:

import http from "k6/http";
import { check } from "k6";

const TOKEN = __ENV.ACCESS_TOKEN; // a pre-minted valid JWT

export const options = {
  scenarios: {
    voting_surge: {
      executor: "ramping-arrival-rate",
      startRate: 200,
      timeUnit: "1s",
      preAllocatedVUs: 2000,
      stages: [
        { target: 10000, duration: "30s" }, // ramp to 10k req/s
        { target: 10000, duration: "60s" }, // hold the surge
        { target: 0, duration: "15s" },
      ],
    },
  },
};

export default function () {
  const res = http.post(
    "https://api.example.com/vote",
    JSON.stringify({ contestant: "A" }),
    { headers: { Authorization: `Bearer ${TOKEN}`, "Content-Type": "application/json" } }
  );
  check(res, { "status is 200": (r) => r.status === 200 });
}

Watch two numbers during the run: the origin's database connection count and the p99 latency at the edge. If the database connection count climbs with request rate, something on the hot path is still reading from the store, and you have not actually offloaded verification. If p99 stays flat while throughput climbs, your edge verification is doing its job. On a modest staging box (for example an AWS t3.medium running Ubuntu 22.04), a single edge node will verify several thousand RS256 tokens per second on CPU alone; your real numbers will differ by hardware and key size, so measure on your own stack rather than trusting a quoted figure.

What Are the Common Mistakes That Sink the Surge?

The most common mistake is treating the JWKS fetch as free. Teams cache the verification result but re-fetch the JWKS per request, and the .well-known/jwks.json endpoint becomes the new bottleneck. Cache the keys by kid for minutes. The second mistake is long access tokens used as a revocation shortcut, which forces a per-request blocklist lookup and reintroduces the database hit you worked to remove. The third is testing only the login endpoint, so the real surge shape (authenticated requests) is never exercised. The fourth is ignoring the audience and issuer claims, which lets a token minted elsewhere amplify abuse traffic into your origin. Most production API security mistakes under load trace back to one of these four. For broader hardening of the token-issuing endpoints themselves, the fundamentals of REST API authentication still apply, surge or not.

Frequently Asked Questions

How many database hits should an authenticated request make during a 10k/sec spike?

Zero on the hot path. Once an edge node has cached the JWKS public key, verifying a viewer's access token is a local signature and expiry check with no network call. The only database hits should come from the small set of writes (login, refresh, vote recording) that you have deliberately isolated behind a connection pooler and a write-behind cache.

Are stateless JWTs less secure than server-side sessions?

They make a different tradeoff, not a strictly weaker one. Server-side sessions allow instant revocation but require a store lookup on every request, which is what saturates under load. Stateless JWTs remove that lookup but accept a revocation lag bounded by the token lifetime. Keeping access tokens at 5 to 15 minutes with refresh tokens narrows that lag to an acceptable window for most OTT use cases.

How often should I rotate JWT signing keys?

Rotate on a fixed schedule (commonly every few weeks to a few months) and immediately on any suspected key compromise. Because each key has a kid and old tokens keep verifying against the old key until they expire, rotation is non-disruptive: publish the new key to your JWKS endpoint, start signing with it, and retire the old key after the longest token TTL has passed.

What is the right access-token lifetime for live events?

For live events, 5 to 15 minutes is a good range. Short enough that a revoked or banned account stops working quickly without a per-request blocklist, long enough that viewers are not constantly refreshing during a 30-minute voting window. Pair it with a refresh token so the viewer experience stays seamless across the event.

Can I do edge JWT verification without a CDN like Cloudflare?

Yes. The pattern is portable: any reverse proxy or API gateway that can run logic close to the user works, including NGINX with a JWT module, Envoy, or an API gateway with a JWT authorizer. The two requirements are the same everywhere, distribute the public key to the verifying layer and cache the JWKS by kid so verification stays local.

Final Thoughts

A 10,000-per-second login surge is survivable when authentication is designed for scale from day one. The winning pattern is simple: stateless JWT validation at the edge, cached JWKS keys, short-lived tokens, and a protected write path that minimizes database dependency. When authentication becomes a signature verification problem instead of a database lookup problem, massive traffic spikes become much easier to handle.

Building and maintaining this infrastructure in-house, however, requires significant expertise in identity, security, scaling, and operations. That's where platforms like MojoAuth can help. MojoAuth provides a scalable authentication infrastructure with support for passwordless login, passkeys, OTPs, social authentication, JWT-based authentication, and enterprise-grade security, allowing engineering teams to focus on their core product instead of building and maintaining authentication systems.

Whether you're preparing for a viral product launch, a flash sale, a ticket release, or a major voting event, the right authentication architecture ensures that your login system remains fast, reliable, and secure—even when thousands of users arrive at the same moment.

Ready to try? Sign up for MojoAuth.

The post The 10k/sec Auth Challenge: Scaling OTT Platforms During Live Voting appeared first on MojoAuth Blog – Passwordless Authentication & Identity Solutions.

*** This is a Security Bloggers Network syndicated blog from MojoAuth Blog - Passwordless Authentication & Identity Solutions authored by MojoAuth Blog - Passwordless Authentication & Identity Solutions. Read the original post at: https://mojoauth.com/blog/10k-per-sec-auth-scaling-ott-live-voting