Exercise 3: Why upsert() Is Used for the Recipe Cache Write — Possible Solution
====================================================================

WHERE THIS PATTERN FIRST APPEARED
------------------------------
Chapter 3 (Barcode Lookup) introduced upsert() for exactly this kind of
check-then-write caching pattern, replacing what would otherwise be a
plain create() following a cache-miss check.

THE SPECIFIC PROBLEM IT SOLVES
------------------------------
A plain check-then-create pattern - look up the cache, and if nothing
is found, create a new row - has a real race condition: if two
requests for the same never-before-cached key arrive close enough
together, both can pass the "not cached yet" check before either one
has written anything, and the second create() then collides with the
primary key (ingredient here, barcode in Chapter 3) that the first
request's write already claimed. upsert() avoids this by being defined
as "create this row if it doesn't exist, otherwise update it" - so the
second request's upsert() for the same key simply updates the row the
first request just created, instead of failing.

WHY THE SAME REASONING APPLIES HERE
------------------------------
The recipe cache faces the identical structural risk: two nearly-
simultaneous requests for the same never-before-looked-up ingredient
could both miss the cache and both try to write a result for it. Using
upsert() here, exactly as in Chapter 3, closes that same race
condition for RecipeCache that it already closed for BarcodeCache.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly traces the pattern back to its actual origin (Chapter 3)
rather than treating it as introduced fresh in this chapter, and it
correctly re-derives the specific race condition upsert() prevents
rather than simply asserting "it's safer" without explaining why.