Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Nonconformist Resilience: DB-backed Job Queues

Nonconformist Resilience: DB-backed Job Queues



John Mileham presents how they use, deploy, and even love Delayed::Job (a database-backed job queue) at Betterment for its transactional enqueue semantics, safe retry with exponential backoff, and its storage model, which lends itself to simple but powerful SLA-based monitoring and alerting. DJ enables engineers to pour their creativity into their features and get resilience by default.


John Mileham is VP of Architecture at Betterment. After a decade building industry-defining products like Berklee Online, he decided to switch to FinTech where he could build industry-defining products that must also protect people's life savings and most sensitive personal information, first at ImpulseSave, and now Betterment.

About the conference

Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Recorded at:

Sep 12, 2017

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Queues & Pub/Sub sucks, long live distributed logs

    by Егор Синькевич,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    In the beginning you highlighting problems related to the "transactionability" in the "traditional" queues or pub/sub messaging architectures. The problems are solved in the relatively new concept of the distributed log that is successfully replaces both queues and pub/sub. In the distributed log architecture the consumer, when requesting messages, provides "offset" of the latest processed message, and so, consumer saves "offset" together, in the same transaction with changes made during message processing results. That is very elegant, cheap, and does not require distributed transactions while let's you to use specialized systems that provides messaging functionality. Have a look on mainly Apache Kafka and new player Apache Pulsar

  • Re: Queues & Pub/Sub sucks, long live distributed logs

    by John Mileham,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Egor,

    I'm familiar. Distributed logs are awesome. They can operate at high throughput, achieve reliable, in-order delivery of messages, and scale out laterally across topics. But for the purposes of the talk, they have the same problem as any other message bus that lives outside your app's primary database.

    To be clear: safe, orderly consumption of messages from a distributed log is not the problem. We agree that's a great story. The problem is at insertion time, and is only relevant if you are using a transactional database as your primary datastore.

    Enqueuing a message if-and-only-if the related database transaction commits is the problem. The talk covers this early on with an example app that must send an email confirmation after signup.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p