# Queues and databases

DevFeed: [Queues and databases](<https://devfeed.tech/articles/queues-and-databases-20669.md>)

Original publisher: [Read original article](<http://antirez.com/news/78>)

Published: 2014-07-14T09:53:34Z

Content type: article

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Messaging](<https://devfeed.tech/topics/messaging.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>), [Network](<https://devfeed.tech/topics/network.md>)

Tags: [applications](<https://devfeed.tech/tags/applications.md>), [consistency](<https://devfeed.tech/tags/consistency.md>), [databases](<https://devfeed.tech/tags/databases.md>), [messaging](<https://devfeed.tech/tags/messaging.md>), [network](<https://devfeed.tech/tags/network.md>)

## AI overview

An explanation of how queues defer work in web applications and how the timing of message acknowledgements affects delivery semantics. Acknowledging before processing can lose messages, while acknowledging after processing can cause redelivery, even with strong queue consistency.

## Source excerpt

Queues are an incredibly useful tool in modern computing, they are often used in order to perform some possibly slow computation at a latter time in web applications. Basically queues allow to split a computation in two times, the time the computation is scheduled, and the time the computation is executed. A "producer", will put a task to be executed into a queue, and a "consumer" or "worker" will get tasks from the queue to execute them. For example once a new user completes the registration process in a web application, the web application will add a new task to the queue in order to send an email with the activation link. The actual process of sending an email, that may require retrying if there are transient network failures or other errors, is up to the worker. Technically speaking we can think at queues as a form of inter-process messaging primitive, where the receiving process needs to acknowledge the reception of the message. Messages can not be fire-and-forget, since the queue needs to understand if the message can be removed from the queue, so some form of acknowledgement is strictly required. When receiving a message triggers the execution of a task, like it happens in the kind of queues we are talking about, the moment the message reception is acknowledged changes the semantic of the queue. When the worker process acknowledges the reception of the message *before* processing the message, if the worker fails the message can be lost before the task is performed at all. If the acknowledge is sent only *after* the message gets processed, if the worker fails or because of network partitions the queue may re-deliver the message again. This happens whatever the queue consistency properties are, so, even if the queue is modeled using a system providing strong consistency, the indetermination still holds true: * If messages are acknowledged before processing, the queue will have an at-most-once delivery property. This means messages can be processed zero or one t