Three patterns, one dashboard.

R7 taught six data-modeling patterns. A workshop is not a new pattern; it is the chapter’s techniques applied to one real consumer. The most useful question the assembly can ask is: which did codemojex actually reach for?

The answer is honest and narrow. codemojex builds three Valkey read-models for its dashboard. Each one applies a pattern from R7. The other three patterns are the honest absences — the game’s scale and domain don’t call for them. The chapter’s thesis closes on that gap.

Codemojex.Board’s moduledoc states: “The leaderboard is one sorted set per game … writes it straight to the board — no tier ladder, no first-mover bonus: the raw linear score is the sole rank. Server-side, with no read-modify-write beyond the best-of fold.” The key is cm:<game>:board — unbraced, unlike EchoMQ’s emq:{q}:…. The <game> segment is a branded GAM id minted at game start.

Two operations keep it current: record/3 writes a scored guess; top/2 reads the top-N for the dashboard or the leaderboard endpoint.

The sorted set is the right read-model here: one ZADD updates the rank, one ZREVRANGE … WITHSCORES reads the top-N for every leaderboard render. The ZSET keeps no history and wastes no memory on old scores — only the player’s best stands. It is exposed at GET /games/:id/leaderboard (the REST endpoint) and broadcast by the room channel on every scored guess.

A second Valkey key tracks which players joined a game: cm:<game>:players, a plain SET. Codemojex.Rooms.add_player/2 adds each player on join:

Codemojex.View.total_players/1 counts it with SCARD:

This is the R7.03 honest contrast. HyperLogLog is the pattern R7.03 taught for large-cardinality uniques: 12 KB fixed memory, ~0.81% error, PFADD/PFCOUNT. codemojex does not use it here. A game’s player count is small — an exact SET costs a few bytes per player id, and the count is exact. HLL is the right move only when the cardinality is so large that storing every id exactly is too expensive and a bounded error rate is acceptable. This game’s scale doesn’t meet that bar.

State the trade both ways: exact SET at small cardinality — zero error, small memory. HyperLogLog at billion-scale — ~0.81% error, 12 KB regardless of cardinality. codemojex chooses the former; the pattern the chapter named is not discarded — it doesn’t fit the workload.

Codemojex.View.game_view/1 folds the Valkey operational state — the board, the player count, the privacy-gated game state — into the player-facing dashboard view. CodemojexWeb.RoomChannel’s moduledoc states: “leaderboard updates without any per-game process … a refresh re-reads the view and the leaderboard.”

The room channel pushes the view to clients over Phoenix Channels whenever a guess is scored (a :scored broadcast) or on a client refresh request. The channel joins the game:<id> PubSub topic at join and receives every scored event for that game without maintaining any per-game server process.

There is no XADD activity stream in codemojex. This is the R5 road not taken: an event-sourced activity feed (XADD to an append-only log, consumers reading from an offset) is the R5 pattern. codemojex pushes a re-read Valkey projection over Phoenix Channels instead — simpler, sufficient for the game’s real-time needs, no log to maintain.

The chapter’s instruction was “know which pattern fits which workload.” The workshop makes it concrete. codemojex uses three of R7’s six patterns. The other three are absent because the game’s scale and domain don’t reach for them — not because they are bad patterns. Every absent pattern is the right tool for a different workload.