Premier League Predictor: FastAPI & Redis — Chapter 5, Exercise 1
=================================================================

TASK
Enter two different guests who happen to share the same first name as
guest:Alan, one after the other. Report each HSET return value and what
HGETALL and HLEN show afterwards, then propose a key scheme that avoids
the collision.

SOLUTION

  key = "fixture:1:predictions"

  await r.hset(key, "guest:Alan", "3-0")   # first Alan
  await r.hset(key, "guest:Alan", "0-2")   # a different Alan

Real results:

  Alan #1: 1
  Alan #2 (different person, same name): 0
  HGETALL -> {'guest:Alan': '0-2'}
  HLEN    -> 1

The second call returns 0 because the field already existed, so Redis
treated it as a correction, not a new prediction. The first Alan's 3-0 is
gone, and one prediction now sits where two were expected. No error is
raised anywhere.

A key scheme that avoids it: identify guests by an ID, not a display name,
and keep the name as data.

  guest:{guest_id}         -> "3-0"           (field in the predictions hash)
  guest:{guest_id}:name    -> "Alan Shearer"   (separate hash or string key)

The ID can come from INCR on a guest:next_id counter — the same atomic
technique Chapter 2 used for team and fixture IDs — so two people who
share a name still get two distinct fields. Alternatively, reject the
write when HSET returns 0 for a guest source, so a collision is at least
reported to the person entering the data.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the collision with real commands rather than asserting it,
reads the return value correctly (0 means "overwrote", not "failed"), and
fixes the actual cause: uniqueness by field name is only as good as the
names, so the key must come from something guaranteed unique.