Challenge 2: Redis or MySQL? — Possible Solution
====================================================================

(a) A user's shopping cart contents during an active session — REDIS.
This is exactly the kind of short-lived, frequently-read-and-updated
data Redis fits well: it needs to be fast (checked/updated on nearly
every page view), and losing it in the rare case of a crash is
inconvenient but not catastrophic — the cart can be rebuilt or the
user can just re-add items. It also naturally expires (Chapter 5) once
a session ends, which Redis handles well via TTLs.

(b) Completed order records for a business's permanent financial
history — MYSQL. This is the textbook case for "must survive a crash
with zero loss" — a business cannot afford to lose a record of a
completed, paid order due to a server restart or crash. This is exactly
the system-of-record role MySQL is built for, with durable, ACID-
compliant writes as its core guarantee, not an optional add-on.

The underlying test in both cases: can this data be lost or become
stale without real consequences (Redis fits), or does it need to be
the permanent, durable source of truth (MySQL/MongoDB fits)?