How it works
Four steps, running only when there is work
Create the queue and its processor
Set the image and command for the processor, the code that handles one message. Also set the parallel limit and the retry limit.
Send messages to the queue
Your app puts work in as messages. The queue keeps them until something picks them up.
The processor handles them
When there is a message, your processor runs. Finishing means the message is acknowledged (ack) and leaves the queue; failing means it is retried up to the attempt limit.
Billed per finished message
Messages that are still waiting are not billed. Only messages that finish processing are counted.
Seven products, one platform
Which one do you need?
The difference is when your code runs: from always on, to not running at all until it is needed.
- What you bring
- An app from the catalog
- When it runs
- Always
- How it is billed
- Monthly
- What you bring
- Your own container image
- When it runs
- Always
- How it is billed
- Monthly, per active minute
- What you bring
- A PostgreSQL database
- When it runs
- Always
- How it is billed
- Monthly
- What you bring
- Static files
- When it runs
- Never
- How it is billed
- Plan + bandwidth
- What you bring
- Code in a container
- When it runs
- On a schedule
- How it is billed
- Per second of execution
- XPod Queueyou are here
- What you bring
- Code or a container
- When it runs
- When messages arrive
- How it is billed
- Per processed message
- What you bring
- One function (handler)
- When it runs
- When called
- How it is billed
- Per call + GB-second
Good for
Background work that suits a queue
Bulk email and notifications
Queue up thousands of emails, then process them one by one without flooding your email provider.
Process uploaded images
Resize, watermark or convert the format every time a user uploads a photo.
Sync to third parties
Push changes to a CRM, data warehouse or partner webhook asynchronously, with retries when the destination is having trouble.
Before you use Queue
Two things you need to know
These aren't technical details you can ignore: left unhandled, both show up as bugs in production.
One message can arrive twice
A network hiccup, or a processor that stops before it can acknowledge, can make the same message get processed again. Write your processor so it is safe to run repeatedly (idempotent). For example, before sending an email, check whether that order number has already been emailed.
Parallel means out of order
When several messages are processed at once, message 3 can finish before message 1. If order matters, turn on the keep-order option when you create the queue; the trade-off is slower processing. For example, an order's status going created, paid, then shipped has to stay in sequence.
How billing works
Per finished message
Rp1,500 per 1 million messages
Counted from messages that finish processing and are acknowledged. There is no free allowance: even the first message counts.
Waiting isn't billed
Messages that are still in the queue and haven't been picked up by any processor don't add to the bill.
Taken from your balance
No card is charged automatically. Charges are taken from your XPod balance; you need at least Rp10,000 to start.
See the pricing details →
When not to use XPod Queue
Queue is not for everything, and that's fine
You need an immediate answer for the user
Queue works behind the scenes and doesn't give a synchronous reply. For requests that must be answered on the spot, use Functions or Run.
Go to XPod Functions →Running at set times is enough
If there is no need to wait for messages to arrive, Jobs is simpler.
Go to XPod Jobs →You only serve static files
If there is no process to run at all, Sites is lighter and cheaper.
Go to XPod Sites →