Why it beats classical scheduling.

Oban is the reference point because it is genuinely good: strict per-commit durability, mature tooling, a queue you can trust. Its bill comes in two parts. First, the database is on the hot path — every enqueue, every dequeue, every heartbeat, every ack is a PostgreSQL round-trip, so the store’s latency and availability gate the queue’s. Second, that durability is single-node: a committed job survives a crash of the worker, but not the loss of the database, unless you bolt on Postgres streaming replication and accept its operational weight. Underneath both sits the one mechanism this whole module turns on: durable throughput is set by how many records ride a single fsync. Oban’s single-insert path commits once per job — one record per fsync — and its insert_all path writes a transaction’s worth at once, closing most of the gap by spreading one fsync across the batch. Memory rides infinitely many records per fsync because it never fsyncs at all; Champ rides K because its checkpoint amortizes the fsync over K records. The spectrum is not four philosophies; it is one dial set to four positions. The platform’s job is to choose where each queue sits — and to make the strict-and-replicated end affordable, which is exactly the corner Oban cannot reach without leaving the single-node world.

The platform’s answer keeps the bus on Valkey — fast, reliable, volatile, off the durable path — and makes the durable record the engine’s own commit. This is the commit-log-as-outbox: built today as EchoStore.Durability.Graft, where an enqueue intent is simply a page commit in a reserved high LSN range (@obx_base = 1 <<< 48), and recovery replays that range above a watermark. Because the intent is a commit, it is atomic and durable in one act — there is no second system to disagree with, so the dual-write problem of the last module never arises. And because the engine is the Chapter III Graft engine, that single commit inherits everything that engine already proves: the OCC base-LSN check, the conditional-write fence, page-rollup replication to Tigris, and log-head recovery. So the enqueue is strict and replicated — the corner Oban misses — while riding the engine’s batch for throughput, and the bus stays fast because none of this is on the enqueue hot path. The same idea is where the platform is headed in the large (ADR-A: the commit-log-as-outbox as the journal, off SQL entirely). The balanced reading is the one the platform settled on: mitigate the single-instance database by making durability a replicated engine commit, and keep a reliable Valkey bus for speed. That is why it beats classical scheduling — not by being less strict, but by being strict in a place that also replicates and never touches the hot path.