05 - Caching and Performance
This track is about making backends fast — and, just as importantly, knowing where they're slow so you fix the thing that matters instead of guessing. It has two halves that meet in the middle: caching (the single highest-leverage tool for read-heavy load — what to cache, which strategy, how entries expire and get invalidated, and how to stack caches into a hierarchy), and general performance and concurrency (finding real bottlenecks by measurement, batching and offloading work, the concurrency-vs-parallelism distinction and Python's GIL, and the profilers and load tests that turn "it feels slow" into a number).
How this track works
- It assumes you finished 04-databases-and-data-layer. That track ended on
query optimization, connection pooling, and a first taste of caching query
results in Redis; this track picks up exactly there and builds the full caching
and performance discipline on top of it.
EXPLAIN ANALYZE, the N+1 problem, and connection pooling from track 04 are assumed knowledge and are revisited here from a caching/performance angle. - All hands-on work uses FastAPI + Redis (redis-py) + Postgres, with
Docker standing up Redis and Postgres. The caching modules use real Redis
commands; the performance modules use real profilers (
cProfile,py-spy) and load tools (hey/wrk/locust). - Every standard module README has the same shape: why it matters, concepts, a command/code reference, hands-on exercises (do them — including at least one "diagnose and fix" scenario each), an independent challenge with no code given, common mistakes, and a checkpoint quiz. Two cumulative reviews (after modules 02 and 06) mix everything so far — take them closed-book.
- Go in order. The track is cumulative: strategies (01) build on fundamentals (00); eviction/invalidation (02) and multi-level caching (03) build on strategies; the web/DB application module (04) uses all of it; the performance half (05–08) generalizes from caching to bottleneck-hunting, scaling, concurrency, and profiling; and the capstone (09) requires the whole track at once.
Modules
| # | Module | What you'll be able to do | Time |
|---|---|---|---|
| 00 | Caching fundamentals | Explain what a cache is, the latency ladder, client vs server vs DB caching layers, and what belongs in a cache vs what doesn't | 60-90 min |
| 01 | Caching strategies | Choose between cache-aside, read-through, write-through, and write-behind by their consistency/latency/complexity tradeoffs | 60-90 min |
| 02 | Cache eviction and invalidation | Pick an eviction policy (LRU/LFU/TTL/FIFO) for an access pattern and design manual/TTL/event-based invalidation | 75-105 min |
| 03 | Multi-level caching | Stack an in-process L1 over a distributed L2 (Redis), avoid the stale-L1 bug, and measure hit ratio per level | 60-90 min |
| 04 | Caching for web apps and databases | Cache static assets/API responses via HTTP/CDN headers and expensive queries in Redis, and defend against cache stampedes | 75-105 min |
| 05 | Performance bottlenecks and identifying them | Systematically find the real bottleneck using response time/throughput/utilization instead of guessing | 60-90 min |
| 06 | Scaling strategies and batch processing | Batch to cut per-item overhead, avoid resource leaks, reduce network overhead, and offload non-critical work | 60-90 min |
| 07 | Concurrency and parallelism | Pick async (I/O-bound) vs multiprocessing (CPU-bound), reason about the GIL, and avoid race conditions | 75-105 min |
| 08 | Profiling and performance testing | Profile with cProfile/py-spy, read a flame graph, load-test, and find the actual bottleneck (not the assumed one) | 75-105 min |
| 09 | Capstone project | Profile a deliberately slow FastAPI+Postgres+Redis service, find the top 3 bottlenecks, and fix them with before/after numbers | 4-6 hrs |
Start here → 00-caching-fundamentals/README.md
Back to main curriculum: ../README.md
Once you've completed this track, the next one is 06-background-processing-and-realtime. It's the natural sequel: the recurring move of this track — "this work doesn't need to finish before I respond to the user; offload it" (write-behind caching, request-path offloading, keeping blocking work off the event loop) — becomes that track's entire premise, turned into real infrastructure: durable task queues, scheduled jobs, retries and idempotency, webhooks, and realtime websocket/SSE features.