Do the slow part later
Sending email, resizing images, calling a payment provider or syncing to another service can take seconds, and can fail. Put that work in a queue and your request finishes at once.
Rimbra keeps each message on disk until your code has handled it. If your endpoint is down or answers with an error, the message waits and is sent again, a little later each time.
Send, receive, done
- 1
Create a queue in the dashboard and point it at one of your apps, or any HTTPS address.
- 2
Send messages with one POST and a Queues API token: JSON or text, up to 128 KB, one at a time or a hundred at once.
- 3
Rimbra posts them to your endpoint in batches, signed with the queue’s secret. Answer 2xx and they’re done.
Switch the queue to pull. Your workers lease messages over the API and ack them when finished.
When something fails
- Each queue sets its attempts (up to 20) and the wait before the first retry. The wait doubles each time, up to an hour.
- After the last attempt a message moves to failed messages. Look at the error, fix your code, then replay one or all of them.
- Your endpoint can finish part of a batch and ask for the rest again.
- Messages can be delayed by up to 12 hours, and a dedupe id stops the same message being queued twice within a day.
Questions
Can a message arrive twice?
Yes, rarely. Delivery is at least once: if your endpoint handles a message but its answer is lost, Rimbra sends it again. Each message keeps the same id across retries, so you can skip ones you have already done.
Are messages delivered in order?
Roughly oldest first, but not strictly. Retries and parallel batches can change the order.
How do I know a delivery came from Rimbra?
Every delivery carries a Rimbra-Signature header: an HMAC-SHA256 of the timestamp and body made with the queue’s signing secret. Check it before you trust the body.
Does queue data count toward storage?
Yes. Messages waiting in your queues count toward your plan’s storage, and are removed once delivered.