Okay.
So it's very important that you understand
the difference between SQS, SNS and Kinesis.
So SQS has a model where consumers pull data
by requesting messages from the SQSQ.
And once the data is processed
then the consumer has to delete it from the queue
so that's no other consumers can read it ever again.
You can have as many workers as you want.
So as many consumers as you want
and they all work together to consume
and delete all the messages from the queue.
You don't need to provision throughput in advance
because it is a managed service
and it can scale to hundreds of thousands
of messages very quickly.
The ordering guarantees are only available
if you enable FIFO queues.
So first it in first out type of queues.
And you also have individual message delay capability
if you want a message to appear to a consumer in the queue
after a certain amount of time, for example, 30 seconds.
When you look at SNS, this is a different model.
This is a pup sub model.
So you push data to many subscribers
and they will all receive a copy
of the message you're sending.
You can get up to 12,500,000 subscribers per SNS topic.
And once the data is sent to SNS, it is not persistent.
That means that if it is not delivered
you have a chance of losing it.
So it's a pub, as I said
and you can scale to hundreds of thousands of topics.
You don't need to provision throughput as well.
And if you want to combine it with SQS, you can.
So using the fan out architecture pattern
you can combine SNS with SQS
or you can combine SNS FIFO topics with SQS FIFO queues.
Okay.
Now finally, Kinesis has two modes of consumption.
You have the standard mode
where consumers pull data from Kinesis.
In which case you get two megabytes per second, per shard
or if you have enhanced fan out type
of consumption mechanism, you have Kinesis, sorry,
that pushes data into your consumers.
In which case you get two megabytes per second, per shard
per consumer, which gives you a much higher throughput
and the ability to have much more applications reading
from your Kinesis stream.
You have the possibility to reply data
because the data is persisted with new Kinesis data stream.
And so Kinesis is going to be used for real time big data,
analytics and ETL.
You will get ordering at the shard level
and you have to specify how many shards you want
per Kinesis data stream in advance.
So you need to scale the shard yourself
and the data will expire after X days.
And at the time of recording
this is between one and 365 days of data retention.
In terms of capacity mode,
we have two modes, the provision mode
in which we specify in advance the amount of shards we want
for Kinesis streams or the on-demand capacity mode,
where the number of shard is adjusted
by Kinesis streams directly for us.
Okay.
So that's it for this summer lecture.
I hope you liked it.
And I will see you in the next lecture.