Forty Thousand Refreshes

An API serves 180,000 requests per second against 2.4 million concurrent sessions. Access tokens are self-contained JWTs with a 900 second lifetime, so a disabled account keeps working until its current token expires. Security wants that window under 60 seconds. Two proposals:

A. Cut the access token lifetime to 60 seconds and leave the resource servers stateless.

B. Keep 900 seconds and have the gateway test every request against a revoked-subject set in Redis.

Steady-state refresh rate is sessions divided by token lifetime:

$R_{900} = \frac{2.4\times10^{6}}{900} \approx 2{,}667\ \text{s}^{-1} \qquad R_{60} = \frac{2.4\times10^{6}}{60} = 40{,}000\ \text{s}^{-1}$

Which reading is correct?

A does not shrink the window at all, because the client still holds a valid refresh token and can keep minting new access tokens after the account is disabled.

A multiplies token-endpoint load by 15 to 40,000 signing operations per second, so B is the cheaper path: one set-membership lookup on an existing hot path costs far less than minting and signing 40,000 fresh tokens every second.

B is the expensive one, because it adds a network hop to all 180,000 requests per second while A only touches the small subset of clients whose token happens to expire.

Neither is needed. exp is checked on every request, so a 900 second token cannot outlive a disabled account by more than the clock skew tolerance.