SQS

Question 1

two patterns of application communication

Answer 1

synchronous and asynchronous communication

Question 2

synchronous communication

Answer 2

your application will be directly connecting to another application of yours.

buying service –> shipping service

when something is bought, we need to talk to the shipping service to send that item that was just bought.

Question 3

asynchronous communication

Answer 3

or event based.

There will be a middleware called a queue that will connect your applications.

So this time the buying service says, hey, someone bought something, and so I’m gonna put that into a queue, and that’s it. And the shipping service says, hey queue, is there something that got bought recently? And the queue will return that element
and the shipping service can do whatever it wants.

So the buying service and the shipping service are not directly connected.

buying service –> queue –> shipping service

Question 4

synchronous between applications can be a little bit problematic sometimes,

Answer 4

if one service overwhelms the other because there is a sudden spike of purchases or whatever,

for example we have a video encoding service, and we need to encode 1,000 videos but usually it’s 10.
Well, our encoding service is going to be overwhelmed and we’re going to have outages.

So, when you have these sudden spikes of traffic or you can’t predict anything, then it’s usually better to decouple your application and have the decoupling layer scale for you.

Question 5

decoupling layer

Answer 5

SQS for a queue model,

SNS for a pub/sub model,

Kinesis, if you do real time streaming and you have like big data.

Question 6

SQS

Answer 6

a queuing service

a buffer to decouple between your producers and your consumers, to decouple applications

Question 7

producer

Answer 7

whatever sends a message into our SQS queue

can be one or more

Question 8

consumers

Answer 8

something needs to process the messages from the queue and receive them

consumers will poll the messages from the queue

you may have multiple consumers consuming messages from an SQS queue

Question 9

throughputs

Answer 9

you can send as many messages per second as you want, and the queue can have as many messages as you want as well.

So there’s no limit on throughputs and no limits in the number of messages in the queue.

Question 10

by default, the message will stay in the queue

Answer 10

for four days and the maximum amount of time
that a message can be in a queue is 14 days.

as soon as you send a message to a queue, it has to be read by consumer and deleted from the queue
after being processed within that retention period,
otherwise, it will be lost.

Question 11

low-latency

Answer 11

whenever you send a message or read a message from SQS, you will get a response very quickly, less than 10 milliseconds on publish and receive.

Question 12

message size

Answer 12

messages in SQS have to be small. They have to be less than 256 kilobytes per messages sent.

Question 13

duplication

Answer 13

it is possible to have duplicated messages

In rare occasions, the retry mechanism might cause duplicate notifications for the same object event.

this is true for Standard SQS, and you have to take this into account in your application

the problem is solved in FIFO SQS and there is also message deduplication solution

Question 14

message order

Answer 14

for standard SQS: It can have out of the order messages, which means it’s best effort ordering,

there is another type of offering from SQS that can deal with that limitation,

Question 15

the producers will send the messages to SQS using

Answer 15

an SDK, software development kits. And the API to send a message to SQS is called SendMessage.

Question 16

consumers can be running on

Answer 16

1. EC2 instances
2. virtual servers on AWS
3. your own on-premises servers
4. Lambda functions on AWS Lambda

Question 17

consumer may receive up to

Answer 17

10 messages at a time

Question 18

the consumer, it’s your code, has a responsibility to

Answer 18

process these messages. For example, insert some orders into an RDS database. something that you have to write with your code.

and then because these messages have been processed, your consumer will go ahead and delete these messages from the queue using the DeleteMessage API.

And this will guarantee that no other consumer will be able to see these messages and therefore, the message processing is complete.

Question 19

multiple consumers will

Answer 19

receive and process these messages in parallel

if somehow a message is not processed fast enough by a consumer, it will be received by other consumers,
and so this is why we have at least once delivery.

And this is also why we have best-effort message ordering.

Question 20

if we need to increase the throughputs because we have more messages,

Answer 20

then we can add consumers and do horizontal scaling

this is a perfect use case for using SQS with your Auto Scaling groups, or ASG.

your consumers will be running on EC2 instances inside of an Auto Scaling group and they will be polling for messages from the SQS queue.

But now your Auto Scaling group has to be scaling on some kind of metric, and a metric that is available to us is the Queue Length. It’s called ApproximateNumberOfMessages.

It is a CloudWatch Metric that’s available in any SQS queue. And we could set up an alarm, such as whenever the queue length go over a certain level, then please set up a CloudWatch Alarm, and this alarm should increase the capacity of my Auto Scaling group by X amount.

And this will guarantee that the more messages you have in your SQS queue, maybe because there’s a surge of orders on your websites, the more EC2 instances will be provided by your Auto Scaling group, and you will accordingly process these messages at a higher throughputs.

we can put producers on EC2 instances inside one ASG and put consumers on EC2 instances in the second ASG = complete decoupling and autoscaling

Question 21

use case for decoupling using SQS

Answer 21

an application that processes videos.

We could have just one big application that’s called a front-end that will take the request and whenever a video needs to be processed, it will do the processing and then insert that into an S3 bucket. But the problem is that processing may be very, very long to do and it may just slow down your websites if you do this in the front-end here.

So instead, you can decouple your application here so that the request of processing a file and the actual processing of a file can happen in two different applications.

Now, when you do the request to process, that file will be in the SQS queue and you can create a second processing tier called the back-end processing application that will be in its own Auto-Scaling group to receive these messages, process these videos, and insert them into an S3 bucket.

So as we can see here with this architecture, we can scale the front-end accordingly, and we can scale the back-end accordingly as well, but independently.

And because the SQS queue has unlimited throughputs and it has unlimited number of messages
in terms of the queue, then you are really safe, and this is a robust and scalable type of architecture. And also, for your front-end, you can use the optimal type of EC2 instances or architecture for your front-end. And for the back-end, maybe if you’re doing some video processing, you can use some EC2 instances
that have a GPU, a graphical processing unit, because you know that these type of instances will be optimal for doing this kind of workload.

Question 22

SQS security

Answer 22

1. encryption in-flight - by sending and producing messages using the HTTPS API
2. at-rest encryption using KMS keys
3. if we wanted to, we can do client-side encryption, but that means that the client has to perform
   the encryption and the decryption itself.
4. For access controls, IAM policies are going to be able to regulate access to the SQS API
5. we also have SQS access policies helpful when you want to do cross-account access to SQS queue, or when you want you to allow other services,
   such as SNS, or Amazon S3, to write to an SQS queue,
   for example, with S3 events.

Question 23

message visibility timeout

Answer 23

when a message is polled by a consumer, it becomes invisible to other consumers. A consumer does a ReceiveMessage request, a message will be returned from the queue. Now the visibility timeout begins.

by default, 30 seconds. During these 30 seconds, the message has to be processed. If the same or other consumers do a message request API call, then the message will not be returned. During the visibility timeout, that message is invisible to other consumers.

Question 24

after the visibility timeout is elapsed

Answer 24

if the message has not been deleted, then the message will be put back into the queue and therefore, another consumer or the same consumer doing a receive message API call will receive the message again, the same message as before.

so if we don’t process a message within the visibility timeout window, then it will be processed twice potentially. Because it will be received by two different consumers, or twice by the same consumer.

Question 25

if a consumer is actively processing a message
but knows that it needs a bit more time to process the message because otherwise, it will go out of the visibility timeout window,

Answer 25

there is an API called ChangeMessageVisibility.

if a consumer knows that a message needs a bit more time to be processed and you don’t want to process that message twice, then the consumer should call
the ChangeMessageVisibility API to tell SQS, hey, do not make that message visible for now, okay?

I just need a bit more time to process this message.

Question 26

how do you set this message visibility timeout?

Answer 26

if you set it to a really, really high value by default, say, hours, and the consumer crashes, then it will take hours until this message reappears, re-becomes visible in your SQS queue, and that will take a lot of time.

If you set it to something really, really low, like a few seconds, what happens that if the consumer doesn’t end up having enough time to process that message
for whatever reason, then it will be read many times by different consumers and you may get duplicate processing.

the visibility timeout should be set to something reasonable for your application and your consumer should be programmed that if they know they need a bit more time, then they should call the ChangeMessageVisibility API to get more time and increase the timeout of that visibility window.

Question 27

dead letter queues

Answer 27

if a consumer fails to process a message within the visibility Timeout Period, the message automatically
goes back into the queue.

Now, if that’s the thing happens very often, that can be a problem. For example, we read again the message.
Maybe there’s something wrong with the message.
Maybe your consumer doesn’t understand the message or can’t process the message.

Then the message will go back into the queue
and it will happen again. We’ll read the message again from SQS, and it will go again back into the queue.
So we can set a threshold to how many times this can happen. After that it will be sent into a dead letter queue, which will contain that message and for later processing. (for debugging)

later on we can analyze this message and understand why they made our application crash or why they were not successfully processed.

Question 28

how long in the dead letter queue

Answer 28

They will expire at some point because there is a limit to the message retention period. And so it’s never a bad idea for your dead letter queues to set a really high retention, maybe 14 days to make sure you give yourself enough time to read the messages, process them and understand what went on with the failure of processing.

Question 29

delay queue

Answer 29

to delay messages so that consumers don’t see them immediately.
up to 15 minutes.
By default, the delay parameter is zero seconds.

After the delay when a consumer polls for messages, it will see that message and receive it successfully.

Question 30

setting delay parameter

Answer 30

you can set a default at the queue level to say all the messages should be delayed by X number of seconds or every time you send a message you can set a per-message delay if you wanted to using the DelaySeconds parameter.

Question 31

SQS FIFO Queues

Answer 31

first in first out

messages will be ordered in the queue and the first message to arrive in the queue will be the first message to leave the queue.

exactly-once send capability by a feature that allows SQS FIFO queue to remove duplicates.

messages will be processed in order by the consumer.

Question 32

SQS FIFO Queues throughput

Answer 32

because we have such a constraint and guarantee about ordering, this SQS queue has limited throughput. So you get 300 messages per second without batching.

Or if you send batches of messages, you can get a throughput of up to 3,000 messages per second.