How data lives
in RAM.

Reach for Redis as a primary store when the data is hot, operational, and tolerant of about a second of loss — and keep it out of Redis when it is money. Two threads run through the chapter. The first is the store as a system of record: with noeviction and an append-only log, the row in Valkey is not a copy of something durable elsewhere — it is the record, and there is no second home to fall back on. The second is memory as a budget: a value in RAM costs more than a value on disk, so the modeling family is the set of techniques that spend that budget well. Each demand below has one matching answer, and the chapter is the set of those answers.

The first module is built; the rest are specified. Each module is a hub with its dives, grounded in the real echo data layer where it has an honest home and in a clean standalone example where it does not.

The hard part is not the structure but the judgment: whose truth is this datum, and what does it cost in RAM. Name the datum and its tolerances — how much loss it can survive, whether it needs a transaction — and the home follows. Redis as a primary database is never a global switch thrown once; it is a per-datum decision made against two axes, and codemojex makes it in the open. Select a datum to see where it lives and why.

The chapter closes with R7.07: codemojex's dashboard read-models, built on the same per-datum discipline R7.01 establishes. Game state — the round leaderboard (Codemojex.Board, the sorted set cm::board) and the per-player guess locks (Codemojex.Locks, the hash cm::lock:) — lives in Valkey because it is hot, operational, and tolerant of about a second of loss. Money — the player balances (Codemojex.Wallet) and the append-only transaction ledger (Codemojex.Ledger) — lives in Postgres because a balance must be exact and must move with its ledger row in one transaction. The read-models are folds of the operational side: the leaderboard a range read, the uniques a probabilistic count, the activity view a replay.

The contrast that frames the chapter is Oban: Oban keeps its jobs in the same Postgres as the application data, so a job and a business row commit in one transaction — one store, full coupling. Echo separates the bus (the job HASH in Valkey) from the store and buys an in-memory hot path plus a durability dial; it gives up that one-transaction coupling. Each design names its trade. EchoMQ chooses the in-memory record and the ~1s AOF bound; the next rungs of the dial carry the record further from loss.

R7 establishes that Redis can be a system of record and how its data is modeled in RAM. The chapter that follows is the operations concern over that same record — running the tier at scale.