Lesson 0008 · Review & retention

Mixed interleaved review

A cross-pillar quiz that jumps between topics on purpose — turning fluency into durable memory.

~12 min14-question mixed quizPlan: retention schedule

You've finished all seven core lessons and answered every check correctly. But answering right just after a lesson is fluency — easy retrieval while the idea is fresh. The real goal is storage strength: recalling it cold, weeks later, with no context to prime you. The way you build that is interleaving — mixing unrelated topics so each question forces you to first decide which concept applies, then retrieve it. It feels harder than a topic-by-topic review, and that difficulty is exactly the point (desirable difficulty). No section headers here on purpose — every question could be from any pillar.

How to take this

Answer from memory, out loud or on paper, before clicking. If you blank on one, that's a signal — note it, and revisit that lesson's glossary entry. A miss found now is a concept saved later.

The mixed quiz

Two clients INCR the same counter concurrently. No update is lost because Redis:

[0001] One thread executes commands one at a time, so each is atomic by construction — no interleaving, no lost update, no explicit lock needed.

A key's Redis Cluster hash slot is computed as:

[0007] 16384 slots; HASH_SLOT = CRC16(key) mod 16384. Each primary owns a subset, and resharding moves slots between nodes with no downtime.

A cache with default settings hits maxmemory. New writes then:

[0003] The default policy is noeviction — it refuses to drop keys and returns OOM on writes. A cache usually wants allkeys-lru or allkeys-lfu.

Which OS setting most amplifies a big instance's snapshot latency spike?

[0005] With Transparent Huge Pages on, copy-on-write copies 2 MB pages instead of 4 KB during a fork — hugely amplifying the latency and memory surge. Redis recommends disabling THP.

"Is user X in this 50M-member collection?" is answered O(1) by:

[0002] Membership → set, SISMEMBER is O(1). SMEMBERS is O(N) and would return all 50M members, blocking the shared thread.

WAIT 2 1000 returning 2 still isn't a durability guarantee because Redis:

[0006] The primary already applied and acked locally; WAIT is a post-hoc check with no rollback and no quorum-commit. A failover can still promote a replica lacking the write.

Many keys warmed together with a flat TTL melt the DB nightly. Cheapest fix:

[0004] Lockstep expiry → stampede. Jitter (base + rand) desynchronizes expiry so keys don't all die at once — the cheapest, always-applicable mitigation.

KEYS * on a huge keyspace is dangerous mainly because it:

[0001] It's one O(N) command on the single command thread — head-of-line blocking. Every client waits until the full scan finishes. Use SCAN instead.

To stop a one-off scan from evicting your hot keys, prefer the policy:

[0003] LRU evicts by recency, so a big scan makes cold keys look "recent" and can evict the true hot set. LFU counts frequency, so rarely-used scan keys go first.

To keep a big-instance snapshot from spiking your serving node, run BGSAVE:

[0005] Offload snapshotting to a replica so the fork/COW pause lands on a node that isn't serving your write traffic. The primary stays responsive.

A client receives -MOVED. Unlike -ASK, it should:

[0007] MOVED = the slot permanently lives elsewhere → update the map and route future keys there. ASK = mid-migration, a one-off ASKING redirect with the map unchanged.

Live "top 10 by score" plus per-player rank is best modelled with a:

[0002] A sorted set keeps members ordered by score: ZADD/ZRANK are O(log N), ZREVRANGE 0 9 is O(log N + M). Re-sorting a list would be O(N log N) per update.

With appendfsync everysec, a crash loses at most about:

[0005] everysec fsyncs the AOF once per second — the default sweet spot. always loses ~nothing but is much slower; no can lose ~30s.

The command that atomically elects one request to rebuild a hot key is:

[0004] SET ... NX succeeds for only the first caller (single-threaded atomicity) — the single-flight lock. Release only your own token via a Lua compare-and-delete.
Score yourself honestly

Any pillar you missed twice is your weak spot — reopen that lesson's cheat sheet today, and re-take this quiz in a few days. Perfect score? Still re-take it spaced out — the retention plan tells you when.

Synthesis — one design, all four pillars

Retrieval quizzes test pieces; real skill is combining them. Bring this to your teacher (me) and reason it out loud — there's no single right answer, and the defending is the point:

The prompt

Design the Redis layer for a global e-commerce cart + product-detail cache: tens of millions of carts, heavy read traffic, occasional flash-sale spikes, and "we can lose a few seconds of cart data but not minutes." Cover: which data structures for cart vs product; caching pattern + TTL/eviction for product detail; how you keep flash sales from stampeding the DB; persistence settings for the durability bar; and Sentinel vs Cluster — and if Cluster, how you keep a cart's keys on one slot without creating hot shards.

Beyond the notebook — acquiring wisdom

You can now reason about Redis from first principles. The last mile of your mission — being the person a team trusts on this — comes from testing these calls against real practitioners:

Primary sources — your ongoing reference

The official Redis docs and antirez's blog are where every claim in this course traces back to. Your compressed version lives in this course's glossary and cheat sheets — revisit those first.

Where this goes next

That completes the core arc: single thread → data structures → caching → persistence → replication → HA → durable review. From here, spacing is the whole game — see the retention plan for when to re-take this quiz, and bring me the synthesis design or any real Redis problem you hit in the wild.

← Lesson 0007 Retention plan → Glossary → All lessons
I'm your teacher for this — tell me your quiz score and which pillar you missed, and we'll drill it. Or take on the synthesis design above and I'll grill you on the trade-offs.