- Queues are limited to 120000 in-flight messages (use more small queues instead of one large queue)
- Queues may have any number of clients sending/receiving messages at once
- Messages are "best-effort ordered" given their distributed nature
- Use the Visibility timeout on queues and messages to ensure that a message is only available to a
ReceiveMessageonce or until the timeout expires - Adjust the visibility timeout in-flight to extend or cancel the timeout
- Messages should be manually deleted from the queue after processing
- Messages have unique IDs, but the receipt handle is also required in order to delete them
- Messages have a
bodyfor data - Message queues define their own line protocol (JSON is a simple human readbale choice)
- Messages may have typed and validated attribues (best used for metadata, not actual data)
- Messages may define timers
- Messages can be batched 10 at a time
- 256KB limit total message size or batch message size
- Even with the 256KB limits, buffering and batching client side may reduce costs
- Long Polling can reduce the number of
ReceiveMessagecalls - Using SNS to "subscribe" to queue may be the best approach for message processors
- Processors are best single threaded single minded connecting to at most to 1 send and 1 receive queue
- Message processors should be idempotent since each message may be delivered/processed more than once