How do you avoid losing a job between saving to the database and sending to the queue?
Answer out loud or in your head first, then compare.
Answer
If I do two independent writes, I can save the job in the database but fail to send the message after a crash. The opposite inconsistency is possible too. One solution is an outbox: in the same transaction I save the business data and a record of the message waiting to be sent.
A separate program reads committed messages and publishes them to the queue. If it stops, it can return to the unsent records. It can still send a message again, though, if the crash happened after publishing but before marking it. So the consumer still needs duplicate protection. An outbox makes two writes in the local database atomic, not all the systems in the world.
Why it matters: An advanced topic that becomes understandable once you know queues and transactions.
Possible follow-ups: How do you detect messages that wait too long to be published?
How did it go? Be honest — “Not yet” puts the question on your review list.
Start with
- D-P01 · What is HTTP, and what do a request and a response look like? — Backend, data and system design
- D-P10 · What is a database transaction? — Backend, data and system design
- D-P13 · What is a message queue, and why do we use one? — Backend, data and system design
Further reading
- AWS Prescriptive Guidance: Transactional outbox(opens in a new tab)Docs; accessed 22.10.2026. The dual-write problem and writing an event in the same transaction.