Message queues

Some work is slow, and the user should not have to wait for it.

Doing work later

Instead of doing slow work during the request, the app saves a job that says what to do. It answers the user right away, and the job runs a moment later. This only works when the user does not need the result to see the next page.

Producer, queue, worker

• The producer adds a message to the queue, like the sign-up code.
• The queue keeps messages safe until someone takes them.
• A worker (also called a consumer) takes a message out and does the job.

Each message goes to one worker. To get through jobs faster, add more workers.

Absorbing spikes

Jobs often come in bursts. Say 600 jobs arrive each minute for 10 minutes, but the workers finish 400 a minute. The queue grows by 200 a minute, to 2,000. If no new jobs come after the burst, the workers clear those 2,000 in 5 minutes. Nothing is lost; jobs just wait. But if jobs arrive faster than workers finish all the time, the queue grows forever, so you need more workers.

At-least-once delivery

A worker takes a message, does the job, then tells the queue it is done (an ack). Only then is the message deleted. If the worker crashes before the ack, the queue gives the message to another worker. So a message may be handled twice. Workers must handle repeats safely, for example by checking "did I already send this email?"

Dead-letter queue

Some messages fail every time, like one with bad data. Retrying it forever wastes work. After a set number of tries, the queue moves it to a dead-letter queue, where a person can look at it.

Remember

• Return fast; do slow work in a worker.
• A queue holds the extra during a burst.
• A message may arrive twice, so handle repeats.
• Messages that keep failing go to a dead-letter queue.