SQS provides a fully managed message queuing service that allows for asynchronous communication between distributed components of an application. It offers features like redundant infrastructure, configurable settings per queue, access control and long polling. SQS promotes loose coupling between application components by allowing them to communicate without requiring that they be available at the same time. It also enables scaling of application components independently through load sharing and asynchronous message processing. Common uses of SQS include work queues, batching operations, request offloading, and fanout patterns for scalability and reliability.

1. SQS
& Loose Coupling
By
Sandip Chaudhari
Director, Beacon Edutech
http://beaconedutech.com

2. About Myself
• 13+ years of professional experience in Software Industry
• Former CTO @ Krossover
• Director @ Beacon Edutech
• Panel Speaker in New York @ NYTech on Benefits of Cloud
for Video and Image:
https://www.nytech.org/events/cloud-video-image
• Blog: http://hashbulb.com
• Twitter: @sandipchaudhari
• Email: sandipchaudhari@gmail.com

3. Queue?

4. Fun Water Queue

5. What is SQS?
• Amazon Simple Queue Service is a fast, reliable,
scalable and fully managed queue service
• Amazon SQS enables asynchronous message-based
communication between distributed components of
an application

6. SQS – What it can do?
• Amazon AWS SQS page:
• SQS makes it simple and cost-effective to decouple the
components of a cloud application
• You can use SQS to transmit any volume of data, at
any level of throughput, without losing messages or
requiring other services to be always available
• With SQS, you can offload the administrative burden of
operating and scaling a highly available messaging
cluster, while paying a low price for only what you use.

7. SQS – Major Features
• Redundant Infrastructure
• Multiple writers and readers
• Configurable settings per queue
• Variable message size (up to 256 KB)
• Access Control
• Delay Queues

8. SQS – Message Visibility Timeout

9. SQS – Message Visibility Timeout
•
The visibility timeout clock starts ticking once Amazon SQS returns the
message
•
During that time, the component processes and deletes the message
•
But what happens if the component fails before deleting the message?
•
If your system doesn't call DeleteMessage for that message before the
visibility timeout expires, the message again becomes visible to the
ReceiveMessage calls placed by the components in your system and it will
be received again
•
If a message should only be received once, your system should delete it
within the duration of the visibility timeout
•
Each queue starts with a default setting of 30 seconds for the visibility
timeout

10. SQS Message Lifecycle

11. SQS Message Lifecycle
• Messages that are stored in Amazon SQS have a lifecycle that is
easy to manage but ensures that all messages are processed.
1.
2.
3.
4.
A system that needs to send a message will find an Amazon SQS
queue, and use SendMessage to add a new message to it
A different system that processes messages needs more messages to
process, so it calls ReceiveMessage, and this message is returned
Once a message has been returned by ReceiveMessage, it will not be
returned by any other ReceiveMessage until the visibility timeout has
passed. This keeps multiple computers from processing the same
message at once.
If the system that processes messages successfully finishes working
with this message, it calls DeleteMessage, which removes the message
from the queue so no one else will ever process it. If this system fails to
process the message, then it will be read by another ReceiveMessage call
as soon as the visibility timeout passes

12. SQS – Long Polling
• Benefit of long polling with Amazon SQS is the
reduction of the number of empty responses, when there
are no messages available to return, in reply to a
ReceiveMessage request sent to an Amazon SQS queue
• Long polling allows the Amazon SQS service to wait
until a message is available in the queue before sending a
response
• So unless the connection times out, the response to the
ReceiveMessage request will contain at least one of the
available messages (if any) and up to the maximum
number requested in the ReceiveMessage call

13. SQS – Delay Queues

14. SQS – Delay Queues
• Delay queues allow you to postpone the delivery of new
messages in a queue for a specific number of seconds
• If you create a delay queue, any message that you send to
that queue will be invisible to consumers for the duration
of the delay period
• You can use CreateQueue to create a delay queue by
setting the DelaySeconds attribute to any value between 0
and 900 (15 minutes)
• You can also turn an existing queue into a delay queue by
using SetQueueAttributes to set the queue's DelaySeconds
attribute

15. SQS Pricing

16. Components

17. Loose – Tight Coupling

18. Loose – Tight Coupling

19. Loose Coupling
• What if the whole
leg was a single
bone?
• Stiff and rigid?
• Or the joins in the
leg bones were
NOT looselycoupled?

20. Thinking…

21. Components and Loose Coupling

22. SQS and Loose Coupling

23. SQS – Common Design Patterns
• Work Queues: Decouple components of a distributed
application that may not all process the same amount of work
simultaneously
• Buffer and Batch Operations: Add scalability and reliability to
your architecture, and smooth out temporary volume spikes
without losing messages or increasing latency
• Request Offloading: Move slow operations off of interactive
request paths by enqueing the request
• Fanout: Combine SQS with Simple Notification Service (SNS)
to send identical copies of a message to multiple queues in
parallel for simultaneous processing

24. Scalability – Cloud Scalability

25. Concurrency and Load Sharing
• Simultaneous access to SQS complements
concurrency
• Concurrent writes and reads promote load sharing
• Sharing load across machines / nodes opens the
door to scalability

26. Sync versus Async
• SQS offers completely asynchronous communication
• Source component can literally send and forget. It
can immediately proceed to further processing
without delay or wait for response
• Visibility timeout assures managed concurrency
• Visibility timeout ensures fail safety - each message
is processed, even on failures. As long as the
message is processed before retention expiry (14
days)

27. Typical Use Cases
• Photo Processing - Instagram
• Number crunching and analytics for reporting
• Offline reports generation
• Video encoding - Krossover
• Email and SMS bulk messaging

28. Case Study
– Krossover Video Processing
• Burst loads – large simultaneous, concurrent uploads
• Video codec encoding is heavy processing
• Large and heavy video processing load demands load sharing
• Group of video encoding machines (upto 50) concurrently
access the uploaded video-load queue
• Once video-load-message is read, the individual machine
encodes the video before the message visibility timeout (set to 8
hours)
• Multiple such simultaneous encoding processes run on each
machine (upto 8)

29. Questions ?