InfoQ Homepage Presentations Nonconformist Resilience: DB-backed Job Queues
Nonconformist Resilience: DB-backed Job Queues
43:30
Summary
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.
Bio
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.
Sep 12, 2017
-
Related Sponsored Content
-
Related Sponsor
/filters:no_upscale()/sponsorship/topic/2c0d72d2-1768-47c2-8f5b-24f3ef0ae0e0/QconNYrsb-1679560094156.png)
Community comments
Queues & Pub/Sub sucks, long live distributed logs
by Егор Синькевич,
Re: Queues & Pub/Sub sucks, long live distributed logs
by John Mileham,
Queues & Pub/Sub sucks, long live distributed logs
by Егор Синькевич,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi,
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.