Queues - Concepts
Content-based deduplication
Content-based deduplication is a setting available for FIFO queues. Enable content-based deduplication if the message body is guaranteed to be unique for each message. A unique hash value is generated from the body of each message, which is used as its deduplication ID. This avoids the need to set a deduplication ID when sending messages. Read more in our dedicated documentation on creating queues.
Credentials
Credentials give services and platforms access to Scaleway Queues, enabling them to connect to the host system. Credentials for Scaleway Queues define whether the bearer is allowed to write, and/or read, and/or manage queues. Refer to our credentials documentation for more information.
Dead-letter queue
A Dead-letter queue (DLQ), or undelivered-message queue, receives and holds messages that cannot be delivered to their destination queues. A DLQ must be of the same type (FIFO or Standard), in the same Project and in the same region as the queue(s) it serves. Each DLQ also has an associated parameter: maximum receive count. A single queue can serve as dead-letter queue to multiple source queues.
If you designate a queue as a DLQ and its storage quota is reached, messages will not be re-driven to the DLQ until enough free space is available again. If your DLQ is at its full quota, free up space by receiving and deleting messages from any queue in your Project.
FIFO
FIFO stands for First In First Out, and represents a type of queue where the exact order of messages is preserved, and duplicate messages are not tolerated. As well as these specificities, FIFO queues support all the same features as the Standard queue type. Consider using FIFO queues for any use cases where the order of messages is critical, such as e-commerce order management systems, systems where one action should not happen until another has been completed, or first-come-first-served ticketing systems.
Message broker
A message broker is a piece of software that allows applications, systems and services to communicate with each other and send/receive data. It facilitates the exchange of information by receiving messages from a producer, and transmitting them to a consumer. Scaleway Queues is a message broker tool based on the AWS SQS messaging system.
Maximum receive count
The maximum receive count is a setting that can be configured for a dead-letter queue. It defines how many times a message can be received by consumers from the source queue before being moved to the dead-letter queue. This value must be between 1 and 1,000.
Message retention period
The message retention period is a setting that can be configured for a queue. It represents the length of time (in seconds) that messages are kept in the queue before being deleted. Setting a longer message retention period allows for a longer interval between a message being sent and it being received. Read more in our dedicated documentation on creating queues.
Messaging and Queuing
Previously, Scaleway Messaging and Queuing was a single product that grouped together three different messaging protocols. It has now been split into three distinct products: NATS, Queues, and Topics and Events.
Queue
Creating a queue with Scaleway Queues facilitates asynchronous communication between different microservices, applications, and platforms. You can create a queue, configure its delivery and message parameters, and then start sending messages to it. Messages are stored in the queue until they are processed and delivered, and deleted once consumed. Read more about creating and configuring queues, or check our tutorial on creating a serverless scraping architecture using a queue to get an idea of what you can do with message queues.
Queue types
When creating queues with Scaleway Queues, two queue types are available. Standard queues provide at-least-once delivery, while FIFO queues offer first-in-first-out delivery, and (unlike Standard queues) guarantee that messages are delivered in order and without duplication. Content-based deduplication is only available for FIFO queue types. Find out more about creating queues with our dedicated documentation.
Queuing
The message queuing model used by Scaleway Queues. It provides a pattern or framework for sending messages, which contrasts with the publish/subscribe model used by NATS and Topics and Events. Queuing is a form of asynchronous service-to-service communication. Whereas with the publish/subscribe model multiple subscribers can receive each message, with the queuing model, messages have just one destination. Messages are stored in the queue until they are processed and delivered, and they are deleted once consumed. This model is used in serverless and microservices architectures.
Queue volume
Queue volume is one of the factors affecting the billing of Scaleway Queues. Queue volume is calculated as the number of messages in a queue, multiplied by the message size. Or, the sum of the size of all messages in a queue.
Region
Scaleway Queues is available in multiple regions. A region designates the geographical area where the service is hosted. Refer to the product availability table to check which regions are available.
Scaleway Queues
Scaleway Queues is a product for creating managed messaging queues based on AWS's SQS protocol. It allows you to implement your messaging queues without the hassle of managing the infrastructure, scaling or updates.
SQS
The Scaleway Queues product is based on the AWS SQS protocol. Simple Queue Service, or SQS, is a distributed message queuing service that supports programmatic sending of messages via web service applications.
Standard
Standard-type queues and topics represent the default queue/topic type, and offer an at-least-once message delivery system. Unlike FIFO queues and topics, standard queues provide only best-effort attempts to deliver messages in order. At-least-once delivery means that it is possible under rare circumstances that the same message may be received more than once.
Visibility timeout
Visibility timeout is a setting that can be configured for a Scaleway queue. It represents the length of time (in seconds) during which, after a message is received, the queue hides it, so it cannot be received again by the same or other consumers. This is useful as the queue itself does not automatically delete messages once they are received, and so prevents consumers from receiving the same message many times before they have finished processing it. Read more in our dedicated documentation on creating queues.