The balanced decision.

The roadmap names the corner directly: Champ is bounded-loss, Oban is strict but single-node unless Postgres replication is bolted on, and Graft already solves the quadrant the other two miss — transactional commits with an LSN log, conditional-write commit, and instant read replicas over object storage. Read the plot and each option fails the target corner for a different reason. Memory sits at the bottom: maximal throughput, off the hot path, but no durability at all — the wrong axis entirely for a durable queue. Champ sits mid-right: fast and off the hot path, but its replication is async and snapshot-grained, so it is bounded-loss, not strict — the right accept tier, not the durable floor. Oban sits top-left: genuinely strict, but with the database on the hot path of every dequeue, heartbeat, and ack, and single-node until you take on streaming replication. Each is missing exactly one property the platform wants together. The commit-log-as-outbox is the only point in the top-right: it is strict and replicated because the intent is a fenced, Tigris-replicated Graft commit (13.2), and it is off the hot path because the bus stays on Valkey and the durable write rides the engine’s batch rather than gating the enqueue. It does not split the difference between the others; it occupies the corner none of them can.

The engineering question this module answers was always narrow: what does a Graft-backed journal in EchoMQ buy over Oban fully backed by PostgreSQL? The balanced reading is the one the platform settled on — mitigate the single-instance database, but keep a reliable Valkey bus. The single-instance database is mitigated because durability is no longer a row in one Postgres; it is a replicated engine commit, recoverable by log-head replay, with the conditional-write fence guarding correctness. The fast bus is kept because none of that durability is on the enqueue hot path — Valkey carries the work, the commit-log-as-outbox carries the guarantee, and they meet only at the drain. Throughput is not sacrificed for this: the durable record rides the engine’s batch, and aligning that commit batch to the consumer’s claim batch — the seam from Module 13.1 — makes enqueue-through-record a single durable, replicated unit. So “it beats classical scheduling” is not a claim that Oban is bad; it is a claim that the platform reaches a corner Oban cannot, by being strict in a place that also replicates and never touches the hot path. That same engine-as-substrate idea is the threshold of the final module: once durable, replicated state is this cheap and this composable, it stops being plumbing for a queue and starts being the foundation for Tables, Properties, and the Branded Component System — the door this course opens last.