Background job queues have moved into the database. Oban in Elixir, River in Go and Solid Queue in Rails all run on PostgreSQL, because a message broker cannot join the transaction that produced the job. Haskell’s options are narrower, and teams needing the same guarantees have tended to build in-house. Arbiter is an attempt to close that gap, and this talk reports on the design decisions where the type system removed work that would otherwise be maintained by hand.

Arbiter enqueues a job in the same transaction as the writes that produced it. It provides at-least-once delivery inside a visibility window, per-group FIFO ordering, dead-letter queues, cron scheduling, job trees, and cross-queue rate and concurrency limits applied inside the claim statement rather than by cooperating workers. It includes a REST API and admin interface, three database backends, and OpenTelemetry tracing.

Queues are declared once, as a type-level list of table names, payload types and result types. Three features derive from that one declaration: the REST API, the rate-limit policies, and the fan-in of a job tree. A type family produces the API from the list, so every route carries the user’s own payload and result types and cannot fall behind it. A free selective functor (Mokhov et al., ICFP 2019), behind a small domain-specific language, lets a migration collect every rate-limit policy the code can reach, removing the need for a separate policy list. A Monoid constraint on the declared result type reduces the fan-in to foldMap. In each case the alternative is writing those facts a second time and keeping the copies in step.

Throughput is bounded by PostgreSQL rather than by the runtime: across the three backends the spread is under 1.5x, while batching the claim and the acknowledgement changes it by 3-4x. Correctness rests on property-based tests that run generated operation sequences against a live database and check the claim protocol’s invariants in SQL after every step.