Promotion & Relegation, and What Redis Alone Can't Model Cleanly

A season ends: the bottom three clubs go down, the other seventeen carry into the next season, and three newly promoted clubs are added by hand. The relegation half is genuinely a one-liner in Redis, thanks to Chapter 7's sorted set. But building the rollover exposes two mistakes in the key design of Chapters 7 and 8 that only show up once there is a second season — and the chapter then does what Chapter 1 promised, an honest accounting of what this variant costs.

A Bug the First Season Couldn't Show

Chapter 7 kept each team's stats in team:{id}:stats — keyed by team, not by season. That works for exactly one season. Playing one game in season 1 and one in season 2, both with those keys:

The fix is to put the season in the key. Chapter 8's totals, records and leaderboard have the same flaw and the same fix:

Relegation: One Call

Chapter 7's table is ordered best first, so the relegated clubs are simply the last three:

That is only meaningful once the season is over. A table half-way through a season ranks clubs on a few games each. The route should refuse to relegate anyone until every team has played all 38 games:

The Rollover, in One Atomic Script

Carrying the survivors forward is several writes that must happen together: create the new season, copy seventeen teams into its membership set, seed each at zero in its table, mark the old season as rolled over, and make the new one current. As in earlier chapters, a Lua script makes that a single unit — and gives a double-click on "rollover" nothing to double:

The route calls season_complete first and returns 409 if it is false, then takes a new season ID from INCR as in Chapter 2, and passes the script the keys it needs.

Relegation Deletes Nothing

Removing a club from the next season is an omission, not a deletion. After the rollover, season 1 still has 20 teams in its Set and 20 in its table, and every team:{id} hash is untouched. The relegated clubs' history is intact and can come back if they are promoted later. The same design choice as the relational siblings, and simpler here because a Set membership is just a list of IDs.

The Three Promoted Clubs

Which clubs are promoted is real-world knowledge no query here could produce, so — as in every sibling — the three are entered by hand through Chapter 3's add-team route, which also enforces the 20-team cap with SCARD. That route needs one change. Season membership now lives in two structures: the Set (Chapter 3) and the table (Chapter 7).

This is the theme of the whole variant showing up once more: where a relational database has one season_teams row that every query reads, this design has two structures that the code must keep in agreement.

What Redis Alone Can't Model Cleanly Here

Chapter 1 asked to be taken on trust that this course was deliberately narrower than its PostgreSQL sibling. Nine chapters of evidence can now be added up. Each item below was checked, not assumed.

1. Durability — the one that matters most

A default Redis server keeps data in memory and only occasionally writes a snapshot. Checked against the standard image: save = 3600 1 300 100 60 10000 (snapshot after an hour if at least one key changed, after five minutes if 100 changed, after one minute if 10,000 changed) and appendonly = no. Two keys were written, then the container was killed abruptly, as in a crash or power loss:

For this app the stakes are specific. The relegation-table and leaderboard are derived and can be rebuilt (Chapter 7 showed that). But the fixtures and the predictions are hand-typed source data — there is nothing to recompute them from. Running this variant as the only copy means either enabling the append-only file or accepting that a crash means re-entering data.

2. Size is not the problem

The usual worry about an in-memory store is fitting the data. Ten seasons of 380 fixtures each — 3,800 fixtures, each with five predictions, scored, with all the tables, stats, totals and leaderboards — came to 15,450 keys and about 1.7 MiB (roughly 170 KiB per season, growing steadily). That fits in memory many thousands of times over.

3. A second axis needs a second structure

"Which seasons has team 8 played in?" has no direct answer, because membership is stored season → teams, not team → seasons. The workable options are a scan or a second index:

It works, and for a few seasons it is instant, but SCAN walks the keyspace rather than using an index. The alternative is a team:{id}:seasons Set that the add-team route also maintains — which is the same "two structures to keep in agreement" cost as the promoted-club bug above.

4. Integrity lives entirely in the application

Across the course, a fixture could reference a team that doesn't exist (Chapter 2), a prediction or a result could be written for a fixture that doesn't exist (Chapters 5 and 6), and a hash could be silently merged into by a reused ID (Chapter 2). Every guard was a Lua script or a route check the author had to remember to write.

Hands-On Exercises