AWS SQS is a web service that provides us with a message queue on the cloud to which a sender process (not humans) can send a message and another reader process (not humans) can retrieve/process/delete the message.
So message queue is basically a temporary repository of messages on the AWS cloud.
SQS is asynchronous. Processes are decoupled (or loosely coupled), distributed, hence highly elastic and scalable.
SQS is pull based system (unlike SNS which is push based). One or more reader programs/lambdas/EC2s can pull messages. You can setup auto scaling to add/remove pulling EC2 instances based on the size the queue.
Messages can be 256 KB max. Text only. You can ASCII encode if you need to send binary files.
Two types of queues:
No order is maintained.
Messages are guaranteed to be sent at-least once. Some rare occasions they are sent twice or more. You need to architect keeping this in mind.
Order of messages is maintained.
Messages are guaranteed to be sent only once.
Multiple ordered messages groups can be hosted in a single queue.
Max 300 transactions per sec.
Messages can be kept in the queue from 1 min to 14 days. Default is 4 days.
Visibility Timeout (VT) of a message is the amount of time it will be invisible in the queue after a reader pulls that message.
Max VT is 12 hours.
After timeout expires, the message will be automatically visible again in the queue. So its the responsibility of the reader to delete the message after processing.
Also make sure message processing is finished before the VT or else you as an architect need to increase the visibility timeout.
Two types of polling possible by the reader
Short polling returns immediately. So it could be expensive if the queue is sparse.
long polling returns only when a message is available in the queue or the long polling timeout whichever is earliest.