This topic explains why the BatchReceiveMessage and BatchPeekMessage operations return fewer messages than the number of visible messages in a queue.
The queue service of Simple Message Queue (formerly MNS) is serverless. It uses multiple compute and data nodes. The number of nodes can range from dozens to hundreds. This number is adjusted based on the overall traffic and message volume in the region. Consecutive messages might be stored on different nodes. For example, Message 1 could be on Node 1, and Message 2 could be on Node 2.
BatchReceiveMessage
When you retrieve messages using the BatchReceiveMessage operation, load balancing first selects a data node. The operation then attempts to retrieve up to 'n' messages in a batch. If any messages are found, they are returned to you immediately. If no messages are found, load balancing selects another data node and retries the operation. This rapid-return design ensures the performance of the operation. All messages are eventually consumed if you continuously call the BatchReceiveMessage operation.
For example, a queue has 11 messages. You call the BatchReceiveMessage operation once to read a maximum of 15 messages. However, the 11 messages are stored on multiple data nodes. The BatchReceiveMessage operation finds any node that has messages and returns them promptly. The number of returned messages might be less than 11.
BatchPeekMessage
This operation uses the same mechanism as BatchReceiveMessage. The main differences are as follows:
BatchPeekMessage: Allows consumers to view messages in a batch. The returned information does not include aReceiptHandle.BatchReceiveMessage: Allows consumers to consume messages from a queue in a batch.