The Compromised Admin Token That Wouldn't Die
The Compromised Admin Token That Wouldn't Die
Your SaaS enterprise application uses stateless JSON Web Tokens (JWTs) for distributed authentication across 80 microservices. Each service verifies JWT signatures locally in-memory using an asymmetric public key (RS256) cached from the authorization server's JWKS (JSON Web Key Set) endpoint, avoiding any central database query on the 90,000 req/s API traffic. Access tokens are issued with a 24-hour expiration (exp) to reduce auth server refresh load. At 14:00, security detects that a senior administrator's laptop was stolen and their active JWT token is currently being used from an unknown IP address to export customer financial records. Security revokes the user's account in the identity database and changes their password. However, for the next 18 hours, every microservice continues to honor the stolen JWT without issue because the cryptographic signature is mathematically valid and the token hasn't expired. You are asked to redesign the token authentication architecture to allow near-instantaneous token revocation (< 5 seconds) without sacrificing the scalability of stateless local token validation.
The Compromised Admin Token That Wouldn't Die
Your SaaS enterprise application uses stateless JSON Web Tokens (JWTs) for distributed authentication across 80 microservices. Each service verifies JWT signatures locally in-memory using an asymmetric public key (RS256) cached from the authorization server's JWKS (JSON Web Key Set) endpoint, avoiding any central database query on the 90,000 req/s API traffic. Access tokens are issued with a 24-hour expiration (exp) to reduce auth server refresh load. At 14:00, security detects that a senior administrator's laptop was stolen and their active JWT token is currently being used from an unknown IP address to export customer financial records. Security revokes the user's account in the identity database and changes their password. However, for the next 18 hours, every microservice continues to honor the stolen JWT without issue because the cryptographic signature is mathematically valid and the token hasn't expired. You are asked to redesign the token authentication architecture to allow near-instantaneous token revocation (< 5 seconds) without sacrificing the scalability of stateless local token validation.
Provide 1–2 precise sentences for each architectural dimension. Each box guides you on what staff-level interviewers evaluate.
Define SLA targets, hard consistency constraints, and conditions the system must never violate.
Quantify throughput (QPS/RPS), read:write ratios, and peak burst multipliers.
Step-by-step path: client ingress → API gateway → queues → background workers → persistence.
Database engine, table schema, partition keys (PK/SK), and durability strategy.
What resource hits saturation first under 10x traffic? (CPU, disk IOPS, connection pools, network).
Worker crashes, network partitions, split-brain, poison pill DLQ, retries, and idempotency.
What did you sacrifice in exchange and why? (e.g. eventual consistency vs latency, cost vs redundancy).