Rachael Adeyemi

Heads up: JWT is not authentication. It's a signed note. Authentication already happened before the JWT was issued. Think about it. A user enters their email and password. Your application verifies the credentials. That verification step is authentication. Only after that does your server generate a JWT. The JWT is simply a signed statement saying: "I already authenticated this user." Later, when the user makes another request, the server verifies the token's signature and trusts the claims inside it. The JWT didn't authenticate the user. Your application did. The JWT is just carrying proof that authentication happened at some point in the past. This distinction matters because many engineers treat JWT as a security solution. It's not. It's a transport mechanism for identity claims. You still need to think about: • Token expiration • Revocation • Refresh tokens • Authorization • Session invalidation A valid JWT only tells you: "Someone successfully authenticated at some point, and this token hasn't been tampered with." Whether that user should be allowed to act right now is an entirely different question.

Backend Engineers throw Redis into every architecture nowadays like it’s a compulsory tech stack. Meanwhile, some applications genuinely do not need Redis at all. So, when exactly should Redis actually be used? Real practical scenarios where Redis makes sense?