Cut Authentication Traffic 50‑Fold with JWT: A Simple Token Strategy

When user volume spikes, many services end up queuing to a central user‑center just to answer the question “who is this user?”. Each request—order, payment, product—hits the same authentication gateway, creating a bottleneck.

In a traditional session design, after a successful login the user’s profile is stored in a central Redis cache and the client receives a session_id. Every subsequent request forces each business service to fetch the session from Redis. Real‑world measurements show the authentication API’s P99 latency at about 15 ms, and the Redis query volume grows linearly with the number of users. Any cache instability can blind all downstream subsystems.

JWT takes a completely different approach: the user’s identity information is encrypted and signed, then handed to the client. Each service can verify the token locally without any network I/O. Verification costs only 0.1–0.5 ms, and the Redis lookup pressure drops to zero.

A JWT consists of three dot‑separated parts: Header (algorithm, e.g., HS256 or RS256), Payload (user ID, nickname, expiration, etc.), and Signature (cryptographic seal over the first two parts). The verification flow has four steps: Base64 decode, read the payload, check expiration, and validate the signature—entirely on the local machine.

Performance testing shows a remote session query P99 of roughly 15 ms versus a local RSA verification of about 0.3 ms, a near‑50× speedup. Services become fully decoupled; even if the user‑center crashes, business logic continues to operate.

The trade‑off is that a token cannot be revoked instantly. If a user is black‑listed, the system must wait for the token’s expiration before the revocation takes effect.

To address the revocation limitation, a double‑token scheme is introduced. An access_token (short‑lived, e.g., 15 minutes) carries identity and permissions and is sent with every request. A refresh_token (long‑lived, e.g., 30 days) is used solely to obtain a new access token.

The refresh flow is transparent to users: when the access token expires, the service returns a 401 response; the client automatically presents the refresh token, receives a fresh access token, and retries the request without user interaction.

This design also covers offline scenarios—if the user‑center is temporarily unavailable, a valid refresh token lets the app continue operating, and once the center recovers it can silently renew the tokens.

Security best practices include: always use HTTPS; set cookies with HttpOnly and SameSite=Strict; avoid storing sensitive data in the payload; and limit refresh attempts per day (e.g., a maximum of 50).

In one sentence, the core idea is “local verification, decentralization”. By replacing a central lookup with a trusted signature, using short‑lived access tokens refreshed by long‑lived tokens, the system reduces authentication traffic by an order of magnitude while balancing security and user experience.

If your architecture still forces every service to queue to a central user‑center for identity, it’s time to consider JWT.