Data Structures and Caching Patterns

1. 1

   Start Redis and try each type

   terminalcopy cmd

   $ docker run -d --name redis -p 6379:6379 redis:8

   alias rc='docker exec -i redis redis-cli'

   rc SET page:views 0 && rc INCR page:views

   rc HSET user:42 name Asha plan pro && rc HGETALL user:42

   rc ZADD leaderboard 1200 asha 950 ravi 1500 mei && rc ZRANGE leaderboard 0 2 REV WITHSCORES

   ── expected output ──

   OK

   (integer) 1

   (integer) 2

   1) "name"

   2) "Asha"

   3) "plan"

   4) "pro"

   (integer) 3

   1) "mei"

   2) "1500"

   3) "asha"

   4) "1200"

   5) "ravi"

   6) "950"

2. 2

   TTLs and expiry

   EX sets seconds; TTL shows what remains (-1 = no expiry, -2 = key gone).

   terminalcopy cmd

   $ rc SET product:42 '{"name":"Mug","price":399}' EX 5 && rc TTL product:42

   sleep 6; rc GET product:42; rc TTL product:42

   ── expected output ──

   OK

   (integer) 5

   (nil)

   (integer) -2

3. 3

   Cache-aside with a stampede lock (Python)

   The rebuild lock means only one request queries the database when a hot key expires; the others wait briefly and re-check. The random jitter spreads expiry times.

   import json, random, time, redis
   r = redis.Redis()
   
   def get_product(pid: int):
       key = f"product:{pid}"
       for _ in range(50):                                   # wait up to ~1s for a rebuild
           if (cached := r.get(key)) is not None:
               return json.loads(cached)
           if r.set(f"lock:{key}", "1", nx=True, ex=5):      # I rebuild it
               try:
                   row = db_fetch_product(pid)               # the expensive query
                   r.set(key, json.dumps(row), ex=300 + random.randint(0, 60))
                   return row
               finally:
                   r.delete(f"lock:{key}")
           time.sleep(0.02)                                  # someone else is rebuilding
       return db_fetch_product(pid)                          # fallback: don't fail the request
   
   def update_product(pid: int, fields: dict):
       db_update_product(pid, fields)
       r.delete(f"product:{pid}")                            # invalidate, don't set

4. 4

   A fixed-window rate limiter

   INCR returns the new count; EXPIRE ... NX starts the 60-second window only on the first request. The app allows at most 5 per window. In production, send both in one pipeline or a MULTI/EXEC so a crash between them can't leave a key without expiry.

   terminalcopy cmd

   $ for i in 1 2 3 4 5 6; do rc INCR rl:user42; rc EXPIRE rl:user42 60 NX > /dev/null; done

   ── expected output ──

   (integer) 1

   (integer) 2

   (integer) 3

   (integer) 4

   (integer) 5

   (integer) 6 <- over the limit: the app returns HTTP 429

Each drill is a real failure mode. Read the scenario and the output, decide what's wrong, then reveal the diagnosis.