Skip to content

Sqs

Basics

  • Public service, fully managed and highly available
  • Queues are of 2 types Standard or FIFO
  • Messages can be upto 256kb in size
  • Clients poll queue to retrieve the messages
  • Once retrieved, the messages are hidden for the length of visibility timeout
  • Client needs to explicitly delete message, otherwise the message reappers on the queue after visibility timeout
  • Dead Letter Queues can be used for repeatedly failing messages
  • Standard Queue - Gurantee atleast once delivery but order of delivery is not guranteed
  • FIFO Queue - Gurantee exactly once delivery & in order of addition. They need to have .fifo suffix
  • FIFO Queue performance is limited to 3000 messages/second with batching & 300 messages/second without batching. Standard queues can scale to near infinity
  • Billing of SQS is based on nnumber of polling requests
  • Short polling immediately returns with every poll constituting to 1 request
  • Long polling can have upto 20 seconds of wait time. Preferred way of polling
  • SQS supports encryption at rest using KMS.
  • Identity policies or queue policies are used to give access to queue. Identity policy is required for cross account access

Extended Client Library

  • Allows large payloads to be processed
  • It uploads payload bigger than 256kb is automatically stored to S3 & link to the bucket is added in the message
  • After receiving the message, when the message is deleted , S3 stored message is also automatically deleted.

Delay Queues

  • Enables delayed delivery to the consumers
  • Visiblity timeout defaults to 30 seconds but user can specify values ranging from 0 seconds to 12 hours
  • A delay queue has DelaySeconds configured. During this period the message is not visible on the queue
  • Max value for Delay is 15 minutes
  • FIFO queues do not support delay

Dead Letter Queues

  • Handling recurring failures
  • Redrive policy specifies the source queue, the dead letter queue & maxreceivecount
  • When receivecount > maxreceivecount and the message is not deleted it is moved to DLQ
  • When a message has lived beyond its retention period, it is dropped. When a message is added to a queue the timestamp is added to the queue
  • When a message is sent to DLQ the timestamp is not reset. So it will be droped if the time has exceeded the retention time. Hence DLQ should have retention period > queue retention period