Challenge 2: Trace a Cache-Aside Flow — Possible Solution
====================================================================

FIRST CALL — getProduct(42), cache starts empty:

1. redis.get("product:42") returns null/nil — the key doesn't exist
   yet, so `cached` is falsy.
2. Since there's no cached value, the code falls through to the
   database query: db.query('SELECT * FROM products WHERE id = ?', [42])
   — a genuine cache MISS, hitting the real database.
3. The result is stored back into Redis: redis.set("product:42",
   JSON.stringify(product), { EX: 300 }) — now cached for 300 seconds.
4. The function returns the product fetched from the database.

SECOND CALL — getProduct(42), called immediately after:

1. redis.get("product:42") now returns the JSON string stored in step
   3 (assuming it's called well within the 300-second TTL) — `cached`
   is truthy.
2. Since there's a cached value, the function immediately returns
   JSON.parse(cached) — a cache HIT. The database is NEVER queried on
   this second call.

WHY THIS MATTERS: the database was queried exactly once across both
calls, even though the product was requested twice — this is the
entire point of cache-aside: absorb repeated reads into Redis, and
only fall through to the real database on a genuine miss.