When to Use Redis Interview Questions

Redis is an in-memory store. I use it as a cache, a session store, a rate-limit counter, a lock, and sometimes pub/sub. Reads are sub-millisecond if the working set fits in RAM. I would use it for hot product pages, session tokens, idempotency keys, and leaderboards with sorted sets. I would not treat it as the source of truth unless I designed persistence and failover on purpose. I would not put large videos in Redis; that belongs in object storage. If the data is written once a day and read once a day, a database is enough. Redis pays off when the same key is read over and over and a cache miss is expensive.

Complex queries, joins, or a bank ledger without a durability plan stay in Postgres. Redis for cache, sessions, rate limits, leaderboards, queues, hot keys. Speed and simple structures, not ad-hoc SQL.

Redis has structures, persistence, replication. Memcached is a dumb blob cache. If I need sets, zsets, Lua, or persistence I pick Redis. I would not say Redis always wins.

Sorted set. ZINCRBY, ZREVRANGE. I still persist a source of truth if scores matter legally. I cap the set if it can grow forever.

Simple commands are extremely fast and latency is predictable. I would not run KEYS * because I block that thread. I use SCAN. Slow O(N) commands are the catch.