You're probably using Redis for one job. There are 13 more, and a few of them work in ways that surprised me even after years of using it.
I just published a breakdown of Redis as what it really is: an in-memory data-structure server, not a cache. A few things genuinely stopped me while making it:
↳ The job queue pattern that quietly drops your task the second a worker crashes, and why it has no built-in fix.
↳ How Redis answers "find drivers near me" without being a geo database at all. The trick is one structure you already use every day.
↳ Counting millions of unique visitors in roughly 12 KB, with one catch that makes it useless for billing.
↳ Why a Redis "distributed lock" can hand the same lock to two workers after a failover, and the one thing that actually protects you.
I'm deliberately not answering these here, because the point is watching how all 14 click into a single mental model: stop asking "should we cache this?" and start asking "which Redis structure fits the problem in front of me?"
The last two use cases are the part I'd most want a backend engineer to see. They change what Redis even is.
Full 22-minute walkthrough: https://youtu.be/dpB28Vn0jgk?si=YwUmst8qfdXj215K
Watch it and tell me which use case you've seen used for the wrong job.