Premier League Predictor: FastAPI & Redis — Chapter 2, Exercise 3
=====================================================================

TASK
Explain, in your own words, why the HSET-merge gotcha and the
missing-foreign-key gotcha are both genuinely the same underlying
limitation wearing two different costumes, rather than two unrelated
bugs. What single sentence about Redis explains both of them at once?

SOLUTION

Both real gotchas this chapter reproduced come down to the exact same
single sentence: Redis stores whatever it's told to store, and never
checks that value against anything else in the database before
accepting it.

The HSET-merge gotcha is that sentence applied to a single key.
Redis doesn't ask "does this key already hold a team, and if so, does
this new write make sense as an update to that same team" -- it just
merges whatever fields it's handed into whatever's already there,
with no concept of "this looks like a completely different logical
entity now." There's no rule anywhere saying a hash's own identity
has to stay consistent across writes, because Redis has no concept of
identity beyond the literal key string itself.

The missing-foreign-key gotcha is the identical sentence applied
across two keys instead of one. Redis doesn't ask "does this
away_team_id value correspond to a team hash that actually exists
somewhere else in the keyspace" -- it just stores the literal string
"999" as a field value, exactly as willingly as it would store a
value that happened to correspond to a real team. There's no rule
anywhere saying a field named *_team_id has any special relationship
to keys named team:{id}, because Redis has no concept of one key's
own value being *about* another key at all.

Both failures, in other words, trace back to the same root cause: a
relational database's real constraints (a UNIQUE/PRIMARY KEY forcing
a duplicate insert to fail loudly, a FOREIGN KEY forcing an invalid
reference to fail loudly) exist specifically because the database
itself understands what a "team," a "fixture," and a "reference
between them" actually mean, and actively enforces that meaning on
every write. Redis understands none of that -- to Redis, every key is
just an independent value, and every hash field is just a string,
with no built-in concept of what any of it represents or how it
relates to anything else. The naming convention this chapter
established (team:{id}, fixture:{id} referencing team IDs) is a real,
human-maintained fiction laid on top of that flat keyspace -- and
both gotchas are simply what happens the moment that fiction isn't
perfectly followed, since nothing in Redis itself is there to catch
the mistake.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies the single shared root cause behind both gotchas --
Redis accepts any write without checking it against the meaning of
any other key or field -- and explains each specific failure as that
same root cause showing up within one key (the merge) and across two
keys (the missing reference), rather than treating them as two
separate, coincidental bugs.