Mid-level Track Roadmap

Pattern: outbox pattern

This course covers the outbox pattern in a Rails application that uses Solid Queue. The queue lives in a separate database, so saving a record and enqueuing a job are two commits that cannot be atomic. The lessons explain why no ordering of the two writes is safe. They show an outbox table that stores the message in the same transaction as the data, and a relay that drains it with FOR UPDATE SKIP LOCKED. They also cover at-least-once delivery, duplicates, adoption cost and when to skip the pattern.

What you'll learn

  • ✓Why two writes to two databases cannot be made atomic
  • ✓Why retries miss the crash window and after_commit only narrows it
  • ✓How to design an outbox table written in the same transaction as the data
  • ✓How a relay claims rows safely with FOR UPDATE SKIP LOCKED
  • ✓At-least-once delivery and the idempotency it requires from consumers
  • ✓When periodic reconciliation is a better choice than an outbox
Free preview · Lesson 1 4 min read

The write that isn't in your transaction

This application enqueues background work in a handful of places: its mailers, notification emails, partner webhooks, and the partner icon fetch. The simplest of them is app/services/admin/partners/save_partner_service.rb, shown here in full:

Read the full lesson free →

Curriculum

7 lessons
Type to start searching...