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

TASK
In your own words, explain why this course frames itself as
"deliberately narrower" than its own PostgreSQL sibling, rather than
simply "a different but equally capable" implementation of the same
spec. What real question is this course trying to honestly answer
that a course confident Redis can do everything wouldn't actually be
answering?

SOLUTION

Framing this course as "a different but equally capable" version of
the same app would quietly assume the answer to the exact question
this course actually exists to test -- whether Redis's own real data
structures are a genuine fit for a problem that includes rich,
relational-shaped history (every fixture and every prediction ever
recorded, queryable in arbitrary combinations). That's not a safe
assumption to make going in, and this chapter already found a
concrete, real reason not to make it: Redis's own sorted sets don't
know what a goal-difference tiebreaker is, don't compute it, and tie
members purely by name -- a real, structural gap this course has to
build around, not something PostgreSQL's own SQL ever had to think
about, since ORDER BY points DESC, goal_difference DESC is a single,
ordinary line of SQL.

Calling the course "deliberately narrower" instead is an honest
admission, made before any code is even written, that the real
comparison this project is running isn't "which of these two stores
wins" -- it's "where, specifically, does Redis's own real strength
(continuously-ordered, low-latency access, exactly what a live
leaderboard wants) actually earn its keep, and where does it
genuinely fall short of what a relational store gets for free." A
course confident Redis can do everything would have every incentive
to quietly work around gaps like the tie-breaking problem without
naming them, presenting a smoothed-over success story rather than a
real, evidence-based answer.

The real question this course is actually trying to answer, honestly,
is: is Redis ever genuinely the right choice for an app shaped like
this one, and if so, for which specific pieces of it? That's a
narrower, harder, more useful question than "can Redis technically be
made to work here somehow" -- and Chapter 9's own dedicated chapter on
what Redis alone can't model cleanly is the concrete, planned place
this course goes to answer it honestly rather than assert it upfront.

WHY THIS WORKS AS AN ANSWER
----------------------------
It identifies that "equally capable" would quietly assume the very
thing this course is meant to test, points to a real, already-found
gap (tie-breaking) as concrete evidence the assumption wouldn't hold,
and frames the course's real goal as an honest, evidence-based answer
to where Redis fits rather than a foregone conclusion that it fits
everywhere.