Challenge 2: Add a Cache-Warming Step — Possible Solution
====================================================================

async function updateProduct(id, changes) {
  await db.query('UPDATE products SET ... WHERE id = ?', [id]);

  const freshProduct = await db.query('SELECT * FROM products WHERE id = ?', [id]);
  await redis.set(`product:${id}`, JSON.stringify(freshProduct), { EX: 300 });

  await redis.publish('product-updates', id);
}

// on every instance, at startup — now re-fetches instead of just deleting
subscriber.subscribe('product-updates', async (id) => {
  const freshProduct = await db.query('SELECT * FROM products WHERE id = ?', [id]);
  await redis.set(`product:${id}`, JSON.stringify(freshProduct), { EX: 300 });
});

WHY THIS WORKS AS AN ANSWER
------------------------------
The updating instance now re-queries the database for the fresh row
immediately after the UPDATE, and writes it directly into ITS OWN
cache with the standard 300-second TTL from Chapter 5 — this instance
never experiences a cache miss on this product at all.

Every OTHER instance, upon receiving the pub/sub notification, does
the SAME thing — re-fetches the fresh data from the database and
writes it into its own local cache — rather than simply deleting the
stale entry (redis.del) and waiting for the next request to trigger a
miss-driven re-fetch.

The trade-off worth noting: every instance now performs its own
database query on every update (N instances = N queries for one
update), rather than the original approach's "one lazy re-fetch
whenever the next real request happens to arrive" — a reasonable
trade for guaranteeing zero cold cache misses after an update, at the
cost of some redundant database load if many instances are running.