Topic 16.5
25 Hands-On Builds, Study Plans, and the Readiness Checklist
In one line
Build the 25 mandatory problems in five levels, follow the study plan for your experience level, and use the final checklist before saying "I know Redis". Building beats reading: each build forces you through atomicity, failure and scale decisions.
Think of it like this
Learning to swim. You can read everything about strokes, but you only really know it after you've swum lengths, got tired, swallowed water and recovered. These builds are your lengths.
Key ideas
- 01
Level 1: Redis CRUD API, user session store, product cache, page-view counter, login attempt counter. Level 2: leaderboard, unique visitor counter, nearby driver search, recent-search history, tag system.
- 02
Level 3: fixed-window limiter, sliding-window limiter, token-bucket limiter, distributed lock with fencing, idempotency middleware. Level 4: job queue, delayed job queue, retry queue with backoff and jitter, dead-letter queue, distributed scheduler.
- 03
Level 5: Redis-backed WebSocket notification system, distributed cache with stampede protection, multi-region cache, a Redis Cluster application with hash tags, and a production-grade rate limiter with metrics and failover tests.
- 04
For each build: write tests for concurrency (many threads), failure (Redis stopped, failover), and scale (a benchmark), and write down what happens in each case. That write-up is your interview story.
- 05
Study plans: 0–2 years: basics → data structures → TTL → caching → counters → rate limiting → transactions (Phases 0–3, 6, 7). 2–4 years: add Lua, Streams, Pub/Sub, locks, stampede, invalidation, persistence, replication, Sentinel, Cluster (Phases 3, 5, 9–12). 4–7 years: internals, sharding, hot and big keys, memory, failover, consistency, fencing, multi-region, observability (Phases 2, 10–14). 7+ years / staff: CAP, coordination, failure domains, capacity planning, cost, SLOs, disaster recovery, and when not to use Redis (Phases 13–16).
Code & diagrams
[ ] Architecture, event loop, RESP, threads [ ] Transactions, WATCH, MULTI/EXEC
[ ] Strings, hashes, lists, sets, sorted sets [ ] Pipelines, Lua, Functions, atomicity
[ ] Bitmaps, HyperLogLog, Geo, Bloom, JSON, vectors [ ] Cache-aside/through/behind, invalidation
[ ] Streams, consumer groups, Pub/Sub [ ] Stampede, penetration, avalanche, warming
[ ] TTL, expiration, eviction, LRU, LFU [ ] Hot keys, big keys, performance, SCAN
[ ] Memory internals, fragmentation, capacity [ ] Locks, safe unlock, Redlock, fencing
[ ] RDB, AOF, fsync, backups [ ] Idempotency, dedup, rate limiting (all 4)
[ ] Replication, lag, stale reads, WAIT [ ] Queues, retries, DLQ, delayed jobs, scheduling
[ ] Sentinel, SDOWN/ODOWN, quorum [ ] Sessions, WebSocket fan-out
[ ] Cluster, slots, hash tags, MOVED/ASK, reshard [ ] Redis + PostgreSQL + Kafka, outbox, CDC
[ ] CAP, partitions, split brain [ ] Spring Boot, clients, serialization
[ ] Security: ACL, TLS, network isolation [ ] Monitoring, slowlog, latency debugging
[ ] Multi-region, DR, upgrades [ ] Failure injection A-O, cost, when NOT to use RedisInterview problem
The problem
Your 8-week plan
You have 8 weeks before interviews for a senior backend role. Plan your Redis preparation using this course and the 25 builds.
Explain it without notes
Recite the reasoning chain and apply it to "design a rate limiter" in one breath.
Practice
Complete one build from each level and write a one-page failure report for each.
Done when you can
I've built at least one project from each of the five levels.
I can tick every item on the readiness checklist without notes.
I answer every Redis design question with the full reasoning chain.