Challenge 1: In-Memory vs. Disk-First — Possible Solution
====================================================================

Redis is faster than MySQL for simple key lookups because reading from
RAM is orders of magnitude faster than reading from disk, even a fast
SSD. MySQL, by design, has to guarantee that once a write is
acknowledged, it's durably stored on disk — every write (and often
every read that isn't already cached in memory) has to go through disk
I/O, transaction logging, and the overhead of a general-purpose query
engine capable of joins and complex filtering.

Redis skips almost all of that for a simple key lookup: the data
already lives in memory, there's no query planner deciding how to join
tables, and the operation is often as simple as a direct hash-table
lookup. That's the entire reason GET key can return in a fraction of
a millisecond.

WHAT REDIS GIVES UP TO GET THIS SPEED: durability by default. Since
data lives primarily in RAM, a crash or power loss can lose data that
was never written to disk — Redis's persistence options (Chapter 8)
are optional add-ons, not an automatic guarantee the way MySQL's
transaction log is. Redis also gives up MySQL's rich query language —
there's no equivalent to a multi-table JOIN or a complex WHERE clause
across many conditions; Redis's speed comes partly from deliberately
NOT supporting that generality.