Introduction

In Amazon SQS, the message body and message attributes serve different jobs even though they travel together. The body should carry the business payload, while attributes carry compact metadata that lets producers and consumers classify or handle the message without parsing the full payload first.

What Belongs in the Message Body

The message body is the main content of the message. In most systems, that means the actual event or command your application needs to process, often encoded as JSON.

1{
2  "orderId": "ORD-10482",
3  "customerId": "C-2007",
4  "eventType": "OrderCreated",
5  "total": 129.95
6}

Typical body content includes:

• domain data such as order IDs, amounts, and timestamps
• nested structures that would be awkward to flatten into attributes
• the full payload needed to complete the work

The body is where you put information that must survive independently of transport-level metadata. If a worker cannot do its job without a field, that field usually belongs in the body.

What Message Attributes Are For

Message attributes are separate typed metadata fields. In SQS they can be String, Number, or Binary, and each message can include up to 10 of them. They are useful when the receiver wants quick routing or classification signals without deserializing the full body.

1import boto3
2
3sqs = boto3.client("sqs")
4
5sqs.send_message(
6    QueueUrl="https://sqs.us-east-1.amazonaws.com/123456789012/orders",
7    MessageBody='{"orderId":"ORD-10482","eventType":"OrderCreated","total":129.95}',
8    MessageAttributes={
9        "eventType": {
10            "DataType": "String",
11            "StringValue": "OrderCreated",
12        },
13        "priority": {
14            "DataType": "Number",
15            "StringValue": "1",
16        },
17    },
18)

Good attribute candidates include:

• event category
• priority
• schema version
• tenant or region identifiers
• tracing or correlation hints

These are all useful before the consumer reads the body in detail.

Why Not Put Everything in Attributes

Attributes are not a second payload channel. They are intentionally limited and are best treated as metadata. According to AWS, attribute components count toward the total message size limit, so duplicating large pieces of data wastes space instead of creating a real advantage.

A useful mental model is:

• body equals the business document
• attributes equal the envelope labels

You read the envelope first to decide what kind of item arrived, then you open the document when you need the full content.

Design Guidance

A practical design pattern is to keep the body complete and keep attributes small, stable, and easy to query. For example:

1{
2  "orderId": "ORD-10482",
3  "customerId": "C-2007",
4  "items": [
5    { "sku": "SKU-1", "quantity": 2 },
6    { "sku": "SKU-9", "quantity": 1 }
7  ]
8}

With attributes such as:

eventType = OrderCreated
schemaVersion = 3
priority = 1

This keeps the message readable while avoiding a bloated attribute set.

One Important FIFO Detail

In FIFO queues with content-based deduplication, AWS computes the deduplication ID from the message body, not from the message attributes. That means changing only an attribute does not change the content-based deduplication hash. If deduplication semantics matter, the body must reflect the meaningful difference.

Body, Attributes, and Consumer Behavior

Consumers usually process the message in two stages:

1. Inspect attributes for quick routing or guard checks.
2. Parse the body to perform the actual business operation.

This can reduce wasted JSON parsing in high-throughput systems, and it keeps the transport metadata separate from application state.

It is also helpful when messages pass through other AWS services. For example, metadata fields are often the cleaner place to store values used by routing policies or integration glue, while the body remains the canonical event data.

Common Pitfalls

• Duplicating the same field in both the body and attributes without a deliberate consistency plan.
• Treating attributes like a second payload channel for large data fragments.
• Forgetting that attributes count toward the total SQS message size and are limited in number.
• Confusing custom message attributes with AWS-managed system attributes.
• Assuming FIFO content-based deduplication will notice attribute-only changes when it actually hashes the body.

Summary

• Put the actual business payload in the SQS message body.
• Use message attributes for small typed metadata used for routing, classification, or quick checks.
• Keep attributes compact and avoid duplicating body fields unless there is a deliberate reason.
• Remember that attributes count toward the total message size limit and are limited in number.
• For FIFO content-based deduplication, the body matters; attributes do not affect the deduplication hash.