1.1 The problem: the same expensive call, over and over🔗

Suppose TerpTasks grows an “Ask AI” box: a student types a question — “What’s due this week for CMSC389A?” — and the server calls an LLM to answer it. That call is slow (a few seconds) and costs money per token. Twenty students in the same section ask the identical question within the hour. Without anything in between, every single one of those twenty requests re-runs the full LLM call:

The fix is the oldest idea in computing: remember the answer you already computed. That’s a cache — and Redis is the tool the industry reaches for to build one, because it answers GET in well under a millisecond:

The first student to ask pays the LLM’s latency and cost; Redis stores the answer; every subsequent identical question is a cache hit answered in microseconds, for free. This exact pattern — LLM cache in front of an LLM call — is the running example for the first half of this lecture, and we will keep building on it until §11.

1.2 What Redis is🔗

Redis (REmote DIctionary Server) is an in-memory, key-value data store: it holds all of its data in RAM and exposes a small set of rich data structures (not just strings) through a simple command protocol.

Plain English. Redis is a giant, extremely fast dictionary/hash-map that lives outside your application process, so multiple processes — your web server, a background worker, a second web server behind a load balancer — can all read and write the same shared state.

Intuition. A Python dict in your web server’s memory is fast but private to that one process, and it vanishes when the process restarts. Redis is that same dict, pulled out into its own long-lived process, reachable over the network, and shared by everyone. You trade a tiny bit of latency (a network round trip, still sub-millisecond on localhost) for sharing and persistence across restarts of your app.

Compare Redis to the databases you already know:

Common misconception: “Redis is a replacement for my database.” It is not, and shouldn’t be. Redis can persist to disk (§8), but its whole design center is speed, not durability guarantees or rich querying. The rule of thumb this lecture builds toward: if losing this data would be catastrophic and unrecoverable, it belongs in Postgres; if losing it means “recompute it” or “a user re-logs-in,” it belongs in Redis.

1.3 The smallest possible example🔗

Every Redis command follows the same shape: a verb, a key, and (sometimes) a value. Start the server (§2) and connect with its command-line client, redis-cli:

SET user:1001 "Alice"
GET user:1001

"Alice"

That’s the whole mental model in two lines: SET stores a value under a key, GET retrieves it. Everything else in this lecture is “what other verbs exist, and what other shapes of value can a key hold besides a string.”

2.1 Running the server with Docker🔗

The fastest way to get a real Redis server running locally is Docker — one container, no system-wide install:

docker run \
  --name redis \
  -p 6379:6379 \
  -d redis

6379 is Redis’s default port. -d runs it in the background. Connect to it with the bundled CLI:

docker exec -it redis redis-cli

and sanity-check the connection with the traditional Redis “are you alive” command:

PING

PONG

If you see PONG, the server is up and every example in this lecture will work against it.

2.2 Connecting from Python🔗

Install the official client:

pip install redis

and connect:

import redis

r = redis.Redis(
    host="localhost",
    port=6379,
    decode_responses=True,   # return Python str, not bytes
)

r.set("name", "Anwar")
print(r.get("name"))

Anwar

The decode_responses=True flag matters. By default the Python client returns raw bytes (Redis itself is byte-string-only under the hood); setting this flag decodes every response to a normal str so your application code doesn’t sprinkle .decode() calls everywhere. Every example in this lecture assumes it’s set.

Common misconception: “I need a database migration / schema before I can start.” Redis is schemaless — there is no CREATE TABLE. You just start writing keys. That’s part of its speed for prototyping, and part of its danger (§9): nothing stops a typo’d key name from silently creating a new, orphaned piece of state.

3.1 Worked example: a user-profile cache field🔗

SET user:101:name Alice
GET user:101:name

"Alice"

Plain English. A string key is exactly the dict entry from §1.3 — one key, one value. The colon in user:101:name has no special meaning to Redis; it’s a convention (“namespacing”) that humans and tools use to group related keys and make them readable, the same way you’d name a variable user_101_name instead of x.

3.2 Worked example: atomic counters🔗

Redis strings that hold integers support atomic increment/decrement — useful for anything you’d otherwise read-modify-write:

SET page_views 0
INCR page_views
INCR page_views
GET page_views

2

Intuition — why “atomic” matters. If two requests both did value = GET counter; SET counter (value + 1) in your application code, a race between them could lose an increment (both read 5, both write 6, one increment vanishes). INCR does the read-modify-write inside Redis, as a single indivisible operation — there is no window where two clients can interleave. This is the same class of bug you’ve seen with concurrent database writes, and the same class of fix (push the read-modify-write into the data store itself).

Common uses: page views, likes, API rate-limit counters (§9), “how many times has this student asked the AI assistant today.”

4.1 EX and TTL🔗

SET weather:fairfax "72F" EX 60
TTL weather:fairfax

45

EX 60 means “expire 60 seconds from now.” TTL reports the seconds remaining (here, we happened to check 15 seconds later). Once it hits zero, the key is simply gone — the next GET returns nothing, as if it had never been set.

Common misconception: “I should just delete keys myself when I’m done with them.” You could, but you’d have to remember to, from every code path, including the ones that crash. EX makes expiration a property of the data, not of your application’s control flow — it happens even if your server dies before it would have gotten around to cleaning up.

4.2 Worked example: caching the TerpTasks AI assistant🔗

Return to §1.1’s problem. Without a cache, every question re-runs the (here, simulated) LLM call:

answer = call_llm(question)   # slow + costs money, every single time

With a Redis cache in front of it:

import redis

r = redis.Redis(decode_responses=True)

def answer(question: str) -> str:
    cached = r.get(question)
    if cached is not None:
        print("Cache hit")
        return cached

    print("Calling AI...")
    result = call_llm(question)          # only runs on a miss
    r.set(question, result, ex=3600)     # remember it for one hour
    return result

Trace it exactly the way §8 of the React lecture traced a click: a student asks “What is RAG?” twice.

Why ex=3600 and not forever? An LLM’s answer to a general question ("What is RAG?") is safe to cache for a long time. A question like “What’s due this week?” has an answer that goes stale the moment an assignment is added — caching it forever would serve students a wrong answer with total confidence. Choosing a TTL is choosing how stale you’re willing to be, in exchange for how much compute/money you save. There is no universally correct number; it’s a product decision, not a technical one.

Practical implication. Notice the cache key is the raw question text. That’s simple but fragile — “What is RAG?” and “what is rag” are different keys and both miss independently. A production system normalizes the key first (lowercase, strip punctuation, or hash a canonicalized prompt) before using it as the Redis key; Practice Exercise 6 asks you to fix exactly this.

5.1 Producer and consumer🔗

LPUSH jobs "process_file1"
LPUSH jobs "process_file2"

LPUSH pushes onto the left end, so the list now reads, left to right:

A worker pulls from the right end with RPOP:

RPOP jobs

"process_file1"

Plain English. Push-left, pop-right (LPUSH/RPOP) gives you FIFO order — first job in, first job out — exactly like a line at a checkout counter. (Using LPUSH/LPOP together would give you a LIFO stack instead; the two ends are symmetric, and which pair you pick decides the ordering guarantee.)

r.lpush("tasks", "summarize_document")
task = r.rpop("tasks")
print(task)

summarize_document

5.2 The problem with RPOP: a worker that spins🔗

RPOP on an empty list returns immediately with nothing. A naive worker loop therefore looks like this:

while True:
    task = r.rpop("tasks")
    if task is None:
        time.sleep(0.1)   # poll again shortly
        continue
    process(task)

This works, but it’s polling: the worker asks Redis “anything for me?” ten times a second forever, even when the queue has been empty for a week. §6 introduces the fix.

6.1 Why background work at all?🔗

A web request should return in milliseconds. “Extract text, summarize, generate embeddings” can take seconds to minutes. The fix is the same producer/consumer split every real system uses (Celery, SQS, RabbitMQ all implement this same idea):

The web server’s only job is to record the job and push it onto the queue; it never touches the slow work itself.

6.2 Job metadata: a Redis Hash🔗

A queue entry needs more than a filename — it needs a status a client can poll (“queued,” “processing,” “completed”). That’s a job for a hash: a Redis value that is itself a map from field names to values, exactly like one row of a table or one small JSON object.

HSET job:1001 filename lecture.pdf status queued
HGETALL job:1001

filename lecture.pdf
status queued

Plain English. Where a string key holds one value, a hash key holds a whole group of named fields under one key — the Redis equivalent of:

{"filename": "lecture.pdf", "status": "queued"}

From Python:

r.hset(
    "job:1001",
    mapping={"filename": "lecture.pdf", "status": "queued"},
)

6.3 BRPOP: a worker that waits instead of spins🔗

Redis has a blocking pop: BRPOP behaves exactly like RPOP, except that if the list is empty, the connection waits (blocks) until something arrives, instead of returning immediately.

job_id = r.brpop("job_queue", timeout=0)

timeout=0 means “wait forever.” This directly fixes §5.2’s spinning worker: no polling loop, no wasted CPU, no artificial 100ms delay before a new job is picked up. The worker process is simply asleep, parked inside the BRPOP call, until Redis wakes it the instant a job is pushed.

Common misconception: “BRPOP polls Redis under the hood, so it’s the same cost as my while loop.” It is not — the blocking is implemented on the server side of the connection; your client makes one call and the TCP connection simply doesn’t get a reply until there is data. Zero wasted round trips.

6.4 Putting it together: submit → queue → process → query🔗

import redis
import time
import uuid

r = redis.Redis(host="localhost", port=6379, decode_responses=True)


def submit_job(filename: str) -> str:
    """Producer: record the job, then queue it."""
    job_id = "job:" + str(uuid.uuid4())
    r.hset(job_id, mapping={"filename": filename, "status": "queued"})
    r.lpush("job_queue", job_id)
    return job_id


def process_job(job_id: str) -> None:
    """Consumer: do the (simulated) work, updating status before and after."""
    r.hset(job_id, "status", "processing")
    time.sleep(2)  # stand-in for extract text / summarize / embed
    r.hset(job_id, "status", "completed")


def worker() -> None:
    """Runs forever in its own process, waiting for jobs."""
    while True:
        _, job_id = r.brpop("job_queue")   # blocks until a job exists
        process_job(job_id)


def get_status(job_id: str) -> dict:
    return r.hgetall(job_id)

Run the producer in one terminal, the worker in another, and query status from a third — this is genuinely three separate OS processes cooperating through nothing but Redis:

Practical implication. Nothing here required the producer and the worker to be the same program, the same language, or even running on the same machine — they only need to agree on Redis’s address and the key naming scheme. This is exactly why real systems (Celery, for instance, uses Redis or RabbitMQ as its broker) build on this pattern: it decouples “accept the work” from “do the work” at the process boundary.

7.1 Worked example: deduplication🔗

SADD students Alice
SADD students Bob
SADD students Alice
SMEMBERS students

Alice
Bob

Alice only appears once, even though SADD was called with her name twice. Plain English: a set is Python’s set(), hosted in Redis and shared across processes.

7.2 Worked example: set algebra for recommendations🔗

Sets support the algebra you’d expect — intersection, union, difference — computed server-side in one call:

SADD cmsc330 Alice Bob Charlie
SADD cmsc433 Bob Charlie David

SINTER cmsc330 cmsc433

Bob
Charlie

Intuition. “Students in both cmsc330 and cmsc433” is exactly the set-theory intersection you’d draw as a Venn diagram — Redis just computes it without your application ever pulling both full lists across the network and diffing them in Python.

Practical implication. Common uses: tags (a post’s set of tags; SINTER finds posts sharing tags), permissions (a user’s set of roles; SISMEMBER checks membership in O(1)), and recommendations (“students who took a class you also took”).

9.1 RDB: periodic snapshots🔗

RDB (Redis Database file) periodically writes the entire in-memory dataset to a single compact file on disk.

Trade-off. Fast to restart from (load one file), small on disk, but you can lose everything written since the last snapshot — if the snapshot runs every 5 minutes and the process crashes 4 minutes after one, those 4 minutes of writes are gone.

9.2 AOF: an append-only log of every write🔗

AOF (Append-Only File) logs every write command as it happens, in order:

SET x 10
INCR x
SET y hello

To recover, Redis simply replays the log from the start. Configure how often the log is flushed to disk with appendfsync:

appendfsync everysec

everysec (the recommended default) flushes once per second — so a crash loses at most about one second of writes, at a small continuous disk-I/O cost. (always flushes every single write for near-zero data loss at real latency cost; no lets the OS decide, for best performance and the weakest guarantee.)

Practical implication. Production Redis often runs both: RDB for fast, cheap backups/restarts, AOF for the tight durability window. But notice the recurring theme of this whole lecture: if a piece of data would be a disaster to lose even for one second, it doesn’t belong in Redis at all — it belongs in Postgres, which is built around exactly that guarantee (transactions, write-ahead logging, replication) from the ground up.

11.1 Repository structure🔗

11.2 docker-compose.yml🔗

services:
  redis:
    image: redis:7
    ports:
      - "6379:6379"

docker compose up -d

11.3 app/cache.py — the AI answer cache🔗

"""AI answer cache for TerpTasks (see lecture §4)."""

import redis

r = redis.Redis(host="localhost", port=6379, decode_responses=True)

CACHE_TTL_SECONDS = 300  # 5 minutes, per the exercise spec


def _fake_llm(question: str) -> str:
    """Stand-in for a real LLM call — replace with an actual API call."""
    return "AI answer for: " + question


def answer(question: str) -> str:
    from app.stats import record_question, record_hit, record_miss

    record_question()

    cached = r.get(question)
    if cached is not None:
        record_hit()
        return cached

    record_miss()
    result = _fake_llm(question)
    r.set(question, result, ex=CACHE_TTL_SECONDS)
    return result

11.4 app/queue.py — the job queue🔗

"""Background job queue for TerpTasks document processing (see lecture §6)."""

import time
import uuid

import redis

r = redis.Redis(host="localhost", port=6379, decode_responses=True)

QUEUE_KEY = "job_queue"


def submit_job(filename: str) -> str:
    job_id = "job:" + str(uuid.uuid4())
    r.hset(job_id, mapping={"filename": filename, "status": "queued"})
    r.lpush(QUEUE_KEY, job_id)
    return job_id


def process_job(job_id: str) -> None:
    r.hset(job_id, "status", "processing")
    time.sleep(1)  # simulate extract → summarize → embed
    r.hset(job_id, "status", "completed")


def worker(run_once: bool = False) -> None:
    """`run_once=True` lets tests exercise one iteration without blocking forever."""
    while True:
        popped = r.brpop(QUEUE_KEY, timeout=0 if not run_once else 1)
        if popped is None:
            return
        _, job_id = popped
        process_job(job_id)
        if run_once:
            return


def get_status(job_id: str) -> dict:
    return r.hgetall(job_id)

11.5 app/stats.py — counters🔗

"""Statistics counters (see lecture §3.2 and §9)."""

import redis

r = redis.Redis(host="localhost", port=6379, decode_responses=True)


def record_question() -> None:
    r.incr("total_questions")


def record_hit() -> None:
    r.incr("cache_hits")


def record_miss() -> None:
    r.incr("cache_misses")


def get_stats() -> dict:
    return {
        "total_questions": int(r.get("total_questions") or 0),
        "cache_hits": int(r.get("cache_hits") or 0),
        "cache_misses": int(r.get("cache_misses") or 0),
    }

11.6 Testing without a real Redis server🔗

Just as the FastAPI/React lectures fake the network boundary in unit tests (a stubbed fetch, a FakeClient), Redis code is tested against fakeredis — an in-memory drop-in that speaks the same Python client API without needing a real server running in CI.

# tests/conftest.py
import fakeredis
import pytest


@pytest.fixture(autouse=True)
def fake_redis(monkeypatch):
    """Replace every module's `r` with one shared in-memory fake Redis."""
    fake = fakeredis.FakeStrictRedis(decode_responses=True)
    monkeypatch.setattr("app.cache.r", fake)
    monkeypatch.setattr("app.queue.r", fake)
    monkeypatch.setattr("app.stats.r", fake)
    yield fake

# tests/test_cache.py
from app.cache import answer
from app.stats import get_stats


def test_second_identical_question_is_a_cache_hit():
    first = answer("What is RAG?")
    second = answer("What is RAG?")

    assert first == second == "AI answer for: What is RAG?"
    assert get_stats() == {
        "total_questions": 2,
        "cache_hits": 1,
        "cache_misses": 1,
    }

# tests/test_queue.py
from app.queue import submit_job, worker, get_status


def test_submitted_job_is_completed_after_one_worker_pass():
    job_id = submit_job("lecture.pdf")
    assert get_status(job_id)["status"] == "queued"

    worker(run_once=True)

    assert get_status(job_id)["status"] == "completed"

pytest -v

tests/test_cache.py::test_second_identical_question_is_a_cache_hit PASSED
tests/test_queue.py::test_submitted_job_is_completed_after_one_worker_pass PASSED

Why fake, not real, Redis in tests? The same reason every earlier lecture faked its I/O boundary: tests that need a live server are slow, flaky in CI, and require infrastructure just to run pytest. fakeredis implements the real command semantics in memory, so the logic under test (cache-hit bookkeeping, status transitions) is verified exactly, with zero setup.

11.7 Running the demo end to end🔗

docker compose up -d          # start real Redis
python -m app.cli

Basic🔗

1. Using redis-cli, SET a key with a 30-second TTL, run TTL on it immediately and again after 35 seconds, and explain the two different outputs you see.

2. Explain, in your own words, why INCR needs to be atomic and what could go wrong if an application implemented the same counter as value = int(r.get(k)); r.set(k, value + 1) instead.

3. Given the hash job:2001 with fields filename=paper.pdf and status=queued, write the single Redis command that updates only its status to processing without touching filename.

4. Two sets, cmsc330 and cmsc433, each list student names. Write the command that finds students in cmsc330 but not in cmsc433. (Hint: look up SDIFF.)

5. A teammate says “let’s just store the whole Task object as one JSON string in a Redis string key instead of using a hash.” Give one concrete scenario from §8 where this choice causes a bug their approach wouldn’t have.

Intermediate🔗

• 6. Fix the cache key. §4.2’s cache uses the raw question text as the Redis key, so “What is RAG?” and “what is rag” miss independently. Normalize the key (lowercase + strip punctuation, or hash the normalized text) before using it in answer(), and write a test proving both spellings now hit the same cache entry.

• 7. Expiring sessions. Store a session as a hash session:<user_id> with fields like logged_in_at, and set a 30-minute TTL with EXPIRE. Write a function touch_session(user_id) that resets the TTL back to 30 minutes on every request (so an active user is never logged out), and explain why EXPIRE on every request, rather than TTL once, is the right approach.

• 8. Leaderboard with sorted sets. Redis has a fifth data structure not covered in lecture: the sorted set (ZADD, ZRANGE), which keeps members ordered by a numeric score. Build a small “AI assistant leaderboard” tracking how many helpful answers each student has rated, using ZADD scores 100 Alice / ZINCRBY, and retrieve the top 3 with ZREVRANGE.

• 9. Priority queue. §6’s job queue processes strictly FIFO. Rebuild it as a priority queue using a sorted set instead of a list (urgent jobs get a higher score), so an urgent document is always processed before a normal one submitted earlier. What does the worker’s pop operation become, and why can’t you use BRPOP anymore?

• 10. Failed jobs and retries. Extend process_job to randomly fail 10% of the time (simulate an extraction error), set status=failed and a retries field, and have the worker re-queue a failed job up to 2 times before giving up and setting status=permanently_failed. Track a jobs_failed counter alongside jobs_completed.

Advanced🔗

• 11. Rate limit the AI endpoint. Using only INCR and EXPIRE, implement allow_request(user_id, limit=5, window=60) that returns False once a user has made more than 5 requests in the current 60-second window, and True otherwise. Handle the edge case of the first request in a window carefully (the key doesn’t exist yet — when do you set its expiration, and what happens if you set it on every call instead of only the first?).

• 12. Real RAG integration. Replace _fake_llm in app/cache.py with a real pipeline: embed the question, query a vector database (or an in-memory stand-in) for the most relevant TerpTasks records, and pass them plus the question to a real LLM API. Keep the Redis caching layer exactly as-is. What does this tell you about where a cache belongs relative to the “smart” part of a system?

• 13. Design for a crash mid-job. §6’s worker sets status=processing then does the work then sets status=completed. If the worker process is killed during the work, the job is stuck at processing forever, and no other worker will ever pick it up (it already left the queue). Design a fix using a combination of a per-job TTL/heartbeat and a periodic “reaper” process, and explain the trade-off between checking too often (wasted work) and too rarely (jobs stuck for a long time before being retried).

Key takeaways🔗

1. Redis is an in-memory key-value store with rich data structures — strings, lists, sets, and hashes cover the overwhelming majority of real use cases, and each maps to a familiar Python type (value, list, set, dict).

2. A cache without expiration is a memory leak. Always attach a TTL (EX/EXPIRE) to cache entries, and choose its length as a product decision about acceptable staleness, not a technical afterthought.

3. Atomic operations (INCR, single-field HSET) avoid the read-modify-write race that plain application-level counters are prone to.

4. Lists plus BRPOP give you a producer/consumer job queue for free — a web request pushes work and returns immediately; a separate worker process blocks efficiently until work exists, instead of polling.

5. Hashes track structured, frequently-updated state (like a job’s status) without the read-whole-object-to-change-one-field trap of storing JSON in a plain string.

6. RDB and AOF trade restart speed against data-loss window — neither makes Redis a system of record; both exist to make Redis’s cache and queue state survive an ordinary restart.

7. Redis owns fast, ephemeral, recomputable state; a real database owns the truth. Every design decision in this lecture — what goes in Redis versus Postgres, how long a TTL should be, whether a crash losing a few seconds of writes is acceptable — comes back to that one line.

Terminology🔗

Common mistakes🔗

• Setting a key with no TTL for data that’s meant to be a temporary cache, so Redis’s memory grows without bound.

• Implementing a counter as application-level read-then-write instead of INCR, introducing a race condition under concurrent requests.

• Storing an entire object as one JSON string, then needing a read-modify-write round trip (with a race window) to update a single field — when a hash would update that field atomically.

• Writing a worker loop around plain RPOP with a sleep(), polling Redis continuously instead of using BRPOP.

• Treating Redis as the permanent record for data that would be a disaster to lose, instead of keeping the source of truth in a real database and using Redis only for what’s cheap to recompute.

• Using raw, un-normalized user input as a cache key, so trivially different inputs (case, whitespace, punctuation) miss the cache independently.

• Forgetting that a worker crash mid-job leaves that job’s status stuck forever, with nothing to notice or retry it (Advanced Exercise 13).

Connections🔗

• Backward: the REST/FastAPI lecture’s TerpTasks is exactly what this lecture adds a cache and a job queue to; the layered-architecture lecture’s “isolate the cross-cutting concern in one layer” is why cache.py/queue.py/stats.py are separate modules rather than inline in route handlers; the testing lecture’s “fake the boundary” philosophy reappears as fakeredis standing in for a live server.

• Forward: the vector-database and RAG lectures fill in _fake_llm’s replacement with real retrieval (Advanced Exercise 12); the deployment lecture covers running Redis (and a worker process) as separate services alongside the API in production; message brokers like Celery, RabbitMQ, and SQS generalize §6’s producer/consumer pattern beyond what a single Redis list can express (priority, delayed delivery, at-least-once acknowledgment).