SQS can actually send up to 10 messages in a single API call, which feels like a hidden superpower for throughput.
Let’s see this in action. Imagine you have a Python script that needs to send a batch of user notifications to an SQS queue. Instead of calling send_message 10 times, we’ll use send_message_batch.
import boto3
sqs = boto3.client('sqs', region_name='us-east-1')
queue_url = 'YOUR_QUEUE_URL' # Replace with your actual queue URL
messages_to_send = [
{'Id': 'msg1', 'MessageBody': '{"user_id": 123, "notification": "New message!"}'},
{'Id': 'msg2', 'MessageBody': '{"user_id": 456, "notification": "Your order shipped."}'},
{'Id': 'msg3', 'MessageBody': '{"user_id": 789, "notification": "Password reset requested."}'},
# ... up to 10 messages
]
try:
response = sqs.send_message_batch(
QueueUrl=queue_url,
Entries=messages_to_send
)
print("Successfully sent messages:")
if 'Successful' in response:
for msg in response['Successful']:
print(f" MessageId: {msg['MessageId']}, Id: {msg['Id']}")
if 'Failed' in response:
print("Failed to send messages:")
for msg in response['Failed']:
print(f" Code: {msg['Code']}, Id: {msg['Id']}, SenderFault: {msg['SenderFault']}, Message: {msg['Message']}")
except Exception as e:
print(f"An error occurred: {e}")
This code snippet demonstrates how to group multiple messages into a single Entries list within the send_message_batch call. Each entry requires a unique Id (up to 128 characters, alphanumeric and hyphens) and the MessageBody.
The core problem send_message_batch solves is reducing the overhead of individual API calls. When you send messages one by one, each send_message operation incurs network latency, connection setup, authentication, and SQS processing time. By bundling up to 10 messages, you amortize this overhead across the entire batch. This is particularly impactful in high-throughput scenarios where you’re sending hundreds or thousands of messages per second. It directly translates to lower costs (fewer API requests) and higher throughput for your application.
Internally, SQS receives the batch, processes each message independently for validity and queue placement, and then returns a consolidated response. This response indicates which messages were successfully sent and which failed, along with error details. This granular feedback is crucial for handling partial failures within a batch.
The Id field for each message within the batch is critical. It’s not the SQS MessageId (which is assigned upon successful delivery), but rather a client-side identifier you use to correlate the response with your original request. This is how you know which of your 10 messages succeeded or failed. For example, if you send 5 messages and 3 succeed, you’ll use those Ids to determine which 2 were problematic.
When constructing your batch, remember that each individual message still adheres to SQS message limits: 256 KB for the message body and 10 attributes, with each attribute name and value having its own size constraints. The total size of the batch itself is also capped at 256 KB. This means you can’t just stuff 10 massive messages into one batch; you need to consider the aggregate size.
One common pitfall when dealing with batch responses is assuming a successful batch means all messages were delivered. The Successful array in the response only confirms that SQS accepted the message and assigned it a MessageId. It doesn’t guarantee immediate visibility or that a consumer has processed it. If a message fails within the batch, SQS will include it in the Failed array, providing a Code and Message to help diagnose the issue.
The next step after mastering batch sending is understanding how to efficiently process these batches on the consumer side using receive_message_batch and delete_message_batch to maintain high throughput and minimize API calls.