Redis

Redis is an in-memory data store: keys hold strings, counters, lists, sets and sorted sets, every command is tiny and atomic, and keys can expire on their own.

redis-cli

redis-cli

  1. > _

Keyspace (in memory)

  • empty

Redis keeps all its data in memory, as keys holding different data types. Commands are tiny and run one at a time.

Step 1 / 12
Keys in memory
0

Step by step

The example above, written out — the same steps the animation plays.

  1. 1redis-cli. Redis keeps all its data in memory, as keys holding different data types. Commands are tiny and run one at a time.
  2. 2SET session:42 "asha" EX 60. A string with a 60-second expiry — a classic session store.
  3. 3GET session:42. Reads are served from memory in microseconds.
  4. 4INCR page:views. INCR creates the counter at 0 and adds 1 — atomically, even with many clients.
  5. 5LPUSH jobs "email:7" "email:8". A list used as a queue: producers push…
  6. 6RPOP jobs. …workers pop from the other end, oldest first.
  7. 7SADD online asha ravi asha. A set ignores duplicates: asha is stored once.
  8. 8ZADD leaderboard 120 asha 95 ravi 140 neha. A sorted set keeps members ordered by score.
  9. 9ZREVRANGE leaderboard 0 1. Top 2 by score, straight from the structure — no sorting at query time.
  10. 10(60 seconds later). session:42 reached its TTL and Redis deleted it.
  11. 11GET session:42. Expired keys are simply gone — perfect for sessions, OTPs and caches.

What's happening?

  1. SET with EX stores a value that deletes itself after its TTL — sessions and one-time codes.
  2. INCR updates a counter atomically, so many app servers can count without losing updates.
  3. Lists act as queues, sets drop duplicates, and sorted sets keep members ranked by score.

Complexity

Time
O(1) for GET, SET, INCR, LPUSH/RPOP, SADD · O(log n) for ZADD
Space
Everything is in RAM

Where you'll meet it

Caching, sessions, rate-limit counters, leaderboards, job queues and pub/sub — usually alongside a main database, not instead of it.

Common mistake

Treating Redis as the only copy of important data without persistence configured — a restart can lose what was in memory.

FAQ

Why is Redis so fast?

Data lives in memory, commands are simple, and a single thread runs them one at a time, so there is no locking.

Is INCR safe with many clients?

Yes. Each command runs on its own, so two INCRs can never interleave and lose an update.

Redis vs a database?

Redis trades durability and querying for speed. Keep the truth in a database and use Redis for fast, often temporary, data.