Redis · Interview

Interviewer Smirked at Redis-Stored Tokens? Here's How to Turn It Into a Design Discussion

By IT规划师 · Nov 3, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

The piece rescues a very common interview scenario from the false binary of stateless-JWT perfection versus stateful-session pragmatism, giving engineers a repeatable framework to justify architectural choices with business rationale and trade-off awareness. For anyone who codes auth systems, it also prods deeper engineering details like token hashing, TTL layering, and user-scoped indexes that separate a hand-wavy answer from a production-grade one.

Summary

In a Chinese tech interview, a candidate who said tokens were stored in Redis got a mocking smile. The author, IT规划师, argues that smile signals either a stress test or a rigid belief that stateless JWT is the only correct answer. The response should not be to argue superiority but to clarify definitions, acknowledge JWT's strengths, then explain why the business required server-side session state.

The article lays out a four-step response: first, concede that pure JWT is elegant; second, describe specific pain points like instant revocation, multi-device limits, and dynamic permission changes that pure JWT can't handle without extra infrastructure; third, proactively admit the costs such as extra Redis calls, middleware dependency, and failover complexity; fourth, state when you would choose JWT, such as for short-lived credentials or open platform calls.

Beyond the conversation strategy, the piece offers concrete technical depth: store only hash or jti, not full tokens; layer TTL for access vs refresh tokens; maintain per-user token sets for bulk logout; and plan for Redis failure with clustering, timeouts, and graded degradation. It closes with a 60-second verbal script and advice to ask the interviewer how they handle session state, turning the interrogation back into a mutual technical discussion.

Takeaways

— The interviewer's smirk at "token in Redis" usually means either a stress test about changing your mind or an assumption that stateless JWT is the only correct answer.

— Clarify the term first: distinguish between opaque random tokens in Redis (distributed session) and JWT + Redis (JWT for identity, Redis for session validity).

— Start your answer by conceding the elegance of pure JWT, then move to business constraints that force server-side session state, such as instant revocation, multi-device control, and dynamic permission changes.

— Proactively name the costs of Redis-backed tokens: extra Redis call per auth, external dependency, and the need for clustering, timeouts, and degradation strategy.

— Know when to pick pure JWT: open platforms, short-lived service-to-service credentials, no real-time revocation needs; choose Redis-backed JWT for admin panels, ToB systems, and strict security requirements.

— In Redis, store a hash or jti of the token, not the full token, to avoid exposing usable credentials if Redis is compromised.

— Layer TTLs: short TTL for access tokens, long revocable TTL for refresh tokens, with effective session expiry being the smaller of JWT exp and Redis TTL.

— Maintain a per-user index like user:{userId}:tokens to support bulk logout of all devices when a password changes.

— For Redis failure, use master-slave or cluster mode, set timeouts on the auth path, and apply graded degradation: reject on admin auth, allow short local cache for low-risk reads.

— JWT blacklist stores only invalidated tokens, while Redis whitelist stores all active sessions; choose based on how frequent logout and multi-device management are.

— Avoid saying JWT is insecure; the issue is how you use it. Never frame the choice as Redis-versus-JWT, but as a set of constraints with trade-offs.

— A 60-second coherent summary should state the business need (instant logout, ban, password change, multi-device), acknowledge the cost (Redis dependency), and end with when you'd choose JWT instead.

Conclusions

The fundamental reason this answer works is that it treats the interview as a requirements-analysis exercise, not a trivia contest; a candidate who can map a technical decision to business pain points demonstrates more seniority than one who memorized the 'stateless JWT is best' sermon.

The article subtly points out that pure JWT revocation is usually implemented by adding a blacklist that still requires Redis-like storage, so claiming JWT is stateless is often a half-truth in real systems with logout or ban requirements.

The suggestion to store token hashes rather than full tokens shows a security mindset beyond basic interview prep; many junior engineers overlook the difference between a reversible credential and a reference to one.

The recommended deflection question at the end ('how do you handle session state?') is a clever negotiation tactic that turns the interviewer's judgment into a shared engineering discussion, but it requires the candidate to be confident enough to ask it without coming across as arrogant.

Concepts & terms

JWT (JSON Web Token)

A signed token format that carries claims about a user's identity, self-contained and stateless; the server can verify its signature without consulting shared storage.

jti (JWT ID)

A unique identifier inside a JWT that can be stored server-side (e.g., in Redis) to revoke or track a specific token without exposing the full token.

JWT whitelist vs blacklist

Whitelist stores all currently valid sessions (so any token not on the list is rejected); blacklist stores only tokens that are expired but have been invalidated early, requiring periodic cleanup.

Distributed session

A pattern where session state is kept in a shared store like Redis, so multiple servers can validate a user's session without sticky routing; often used with opaque tokens or session IDs.

TTL (Time-To-Live)

The expiration time set on a Redis key; for tokens, it defines the valid duration of a session entry and must be coordinated with the JWT's exp claim.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗