SevyDevy

Module 3 · Serving More People, Faster · Lesson 12 of 35

What is Redis used for? A fast shared memory for many servers

12 minFree System design course · Beginner to intermediateLesson 3.5By Saket Bhatnagar

Researched and drafted with AI, reviewed and edited by Saket Bhatnagar.

In short

  • What is Redis used for? Redis is a fast store in memory that many servers share, mostly as a cache, a session store and a counter.
  • The usual pattern: check Redis first, and on a cache miss read the database and save the answer with a TTL.
  • Redis forgets when it restarts or fills up, so the database stays the truth and must survive an empty Redis.
Soon

Video lesson · coming soon

What is Redis used for? One shared rack that forgets

Lala, your AI mentor, will walk you through this lesson in a short animated video. Until then, everything is here to read and try.

  1. 01 Two phones, two seat maps
  2. 02 The shared tiffin rack
  3. 03 Ask Redis, then the database
  4. 04 Cache it or not?
  5. 05 7 pm: the rack is wiped
  6. 06 Practise cache-aside out loud

The database was 95% busy, so Arjun’s first cache gave each of SeatJaldi’s four servers its own seat-map copy, refreshed every 2 seconds. Meera Kulkarni walks over with two phones. “Same match, same second. Why does this one show A12 free and that one sold?”

Arjun Nair works it out. Each phone reached a different server, and each server had copied the map at a different moment. Four copies, four ages.

So Arjun rents one shared Redis store for ₹3,500 a month. The seat map goes there, and the phones agree; the session store from lesson 9 runs inside it too. Then one evening at 7 pm it restarts for maintenance, comes back empty, and the database is flooded. Lesson 11 warned that an empty cache sends every read to the database. Why was nothing ready for it, and what else did the restart wipe?

What is Redis used for?

Redis is a store in memory that many servers share, mostly used as a cache, a session store and a counter. Memory is the computer’s fast working space, and a restart wipes it. Disk is slower, but it keeps data after a restart.

SeatJaldi runs one Redis node beside its four servers.

One Redis node for four servers

Every server asks the one Redis node first, and the database only on a cache miss.

Diagram connections:

  • Phones to Four servers (Seat map?)
  • Four servers to Redis node (Check first)
  • Four servers to Database (On a cache miss)
  • Four servers: Keep no copy of their own.
  • Redis node: One shared copy, ₹3,500 a month.
  • Database: The source of truth.

The one idea to keep: Redis is a small, fast rack that forgets. Check it first, and fall back to the canteen.

  • Shared: one copy for every server, so every phone sees the same answer.
  • Small and fast: memory is quick, but costly and limited.
  • Forgetful: a restart, a full memory or a timer can wipe any entry.

You have met fast stores like this already:

  • After an app update, the first minute is slow, then quick. A fast store was refilling.
  • An OTP, a one-time password, dies in minutes. It sits in a fast store with a short timer.
  • A “people watching” counter jumps about, and nobody minds a second’s lag. It lives in memory.
In-memory cache vs database (read times are teaching numbers)
QuestionRedis (the rack)Database (the canteen)
One read takesAbout 0.5 millisecondsAbout 5 milliseconds
After a restartCan be emptyEverything is still there
The truth?Not for data you cannot loseAlways

What is the cache-aside pattern?

Cache-aside means the server checks Redis first, and on a cache miss reads the database and saves the answer in Redis with a TTL. It is Farhan checking the rack, then walking to the canteen.

Cache-aside: check Redis, then the database

A cache hit returns at once; a cache miss reads the database and saves the answer in Redis with a TTL. Redis never calls the database itself.

Diagram connections:

  • Request arrives to Found in Redis? (Ask)
  • Found in Redis? to Answer from Redis (Hit)
  • Found in Redis? to Read the database (Miss)
  • Read the database to Save with a TTL (Answer)
  • Save with a TTL to Response to phone (Respond)
  • Answer from Redis to Response to phone (Respond)
  • Request arrives: Phone to server: the seat map for match 42.
  • Found in Redis?: Server asks Redis for the key seatmap:match-42.
  • Answer from Redis: Fast path: about 0.5 milliseconds.
  • Read the database: Slow path: about 5 milliseconds.
  • Save with a TTL: Kept in Redis for 2 seconds.
  • Response to phone: The seat map goes back.

There is another way to fill the rack. The cook puts a fresh box on it every time a meal changes.

Try it yourselfCache-aside or write-through?Flip each card to compare cache-aside with write-through.
Try it yourselfCache it or not?For each piece of SeatJaldi data, choose whether it goes in Redis, and for how long.

What just happened? Each time you asked how often the data changes, and who an old copy hurts. The match schedule changes a few times a week, so an hour is fine.

What happens when Redis restarts or fills up?

When Redis restarts it can come back empty, so every request rushes to the database at once. Arjun had turned off saving to disk, which some cache nodes do, so it came back with nothing.

Lesson 11’s cold start, at full size: 500 reads a second became all 10,000, 20 times the load, on a database already 95% busy.

Everyone was also logged out, because the sessions lived in Redis. No booking was lost, because bookings live in the database. When the rack fills up, Redis clears entries by a rule you choose.

With cache-aside, evicting a copy loses nothing. The next cache miss refills the key.

How do you size, evict and protect a Redis cache?

By default Redis has no memory limit and evicts nothing, so set maxmemory and pick a maxmemory-policy:

  • allkeys-lru removes the least recently used keys; the Redis docs call it a good default.
  • noeviction removes nothing: writes that add data fail with an error, while reads still work.
  • volatile- policies remove only keys with a TTL, and act like noeviction if none have one.
  • If Redis saves to disk, set maxmemory below the machine’s memory, because saving needs spare room the limit does not count.

To keep a cache stampede small, add a random extra to each TTL so keys do not expire together. Let the first cache miss refill a key while others wait. Fill Redis with the busiest keys before traffic arrives, called warming it, and cap requests to the database.

On a write, update the database, then delete the key; the TTL catches a missed delete. One node is a single point of failure, so never keep the only copy of anything important on the rack. allkeys-lru can evict logins too; the Redis docs suggest a separate node for keys you want kept.

Here is cache-aside in Python. It assumes a Redis client named cache, created with a short socket_timeout, and a db.query helper returning a list of rows.

python
import json
from redis.exceptions import RedisError

def get_seat_map(match_id):
    key = f"seatmap:match-{match_id}"
    try:
        cached = cache.get(key)
    except RedisError:
        cached = None
    if cached is not None:
        return json.loads(cached)  # cache hit
    rows = db.query(
        "SELECT seat_code, status FROM seats WHERE match_id = %s", (match_id,))
    try:
        cache.set(key, json.dumps(rows), ex=2)  # cache miss: keep 2 seconds
    except RedisError:
        pass
    return rows

What just happened? A cache hit returns at once; a cache miss reads the database and saves the answer for 2 seconds. If Redis is down, every call goes to the database.

Try it yourself

  1. Multiply

    How many boxes does the rack hold? Assume 2 lakh cached entries, such as one seat map per match section, of about 4 KB each. Work out 2,00,000 × 4 KB in MB (1,000 KB is 1 MB).

  2. Add overhead

    Assume Redis needs a quarter more for bookkeeping.

  3. Fit a limit

    With overhead each entry takes 5 KB. How many fit in 500 MB?

  4. Check your answer

    You are right with 800 MB of data, 1,000 MB (about 1 GB) with overhead, and 1 lakh entries in 500 MB. So a 500 MB limit holds only half, and eviction drops the rest.

Arjun draws the rack for Meera: shared, so the phones agree; small, so it forgets; and not the truth, because the canteen is.

So how did a cache take the database down? It stopped standing in front of it. A 95% hit rate let 500 of 10,000 reads a second through; an empty rack let all 10,000 through. Now Arjun spreads expiry times, lets one request refill each key, and warms Redis before traffic returns.

Then Meera opens her inbox. Posters and app files still load slowly for Anil in Kochi. The servers sit in the cloud provider’s Mumbai data centre. Is it distance?

Check yourself

Check yourself

Redis restarts at 7 pm. Before that, 10,000 seat-map reads a second had a 95% hit rate. What does the database see right after?

Pick an answer to see why it is right or wrong.

Check yourself

Why does evicting a key from a cache-aside cache lose no data?

Pick an answer to see why it is right or wrong.

Remember these three

  1. Redis is a small, fast rack that forgets: check it first, and fall back to the database.
  2. Cache-aside fills Redis on a cache miss with a TTL; a write updates the database and deletes the key.
  3. An empty Redis sends everything to the database, so spread expiry, refill once, and make sure the database survives.

Questions people ask

What is Redis used for?
Redis is used as fast shared memory for many servers. Its common jobs are caching data that is read often, storing sessions, counters, and short-lived codes such as OTPs.
What is the cache-aside pattern?
Cache-aside means the app checks the cache first. On a cache miss, it reads the database and saves the answer in the cache with a TTL, so the next request is fast.
Is Redis a database or a cache?
Redis is a data store in memory, mostly used as a cache. It should not replace your main database, because memory is small, and Redis can lose data on a restart.

Sources and further reading