Let's talk about messaging and queuing. In the coffee shop, there are cashiers taking orders from the customers and baristas making the orders. Currently the cashier takes the order, writes it down with a pen, and paper and delivers this order to the barista. The barista then takes the paper and makes the order. When the next order comes in the process repeats. This works great as long as both the cashier and the barista are in sync. But what would happen if the cashier took the order and turned to pass it to the barista, and the barista was out on break or busy with another order? Well, that cashier is stuck until the barista is ready to take the order. And at a certain point the order will probably be dropped so the cashier can go serve the next customer. You can see how this is a flawed process, because as soon as either the cashier or barista is out of sync, the process will degrade. Causing slowdowns in receiving orders and failures to complete orders at all. A much better process would be to introduce some sort of buffer or queue into the system. Instead of handing the order directly to the barista, the cashier would post the order to some sort of buffer like an order board. This idea of placing messages into a buffer is called messaging and queuing. Just as our cashiers sends orders to the barista, application send messages to each other to communicate. If applications communicate directly like our cashier and barista previously, this is called being tightly coupled. A hallmark trait of a tightly coupled architecture is where if a single component fails or changes, it causes issues for other components or even the whole system. For example, if we have application A and it is sending messages directly to application B. If application B has a failure and cannot accept those messages, application A will begin to see errors as well. This is a tightly coupled architecture. A more reliable architecture is loosely coupled. This is an architecture where if one component fails, it is isolated and therefore won't cause cascading failures throughout the whole system. If we coded the application to use a more loosely coupled architecture, it could look as follows, just like our cashier and barista, we introduced a buffer between the two. In this case, we introduced a message queue, messages ascend into the queue by application A and they are processed by application B. If application B fails, application A doesn't experience any disruption. Messages being sent can still be sent to the queue and will remain there until they are eventually processed. This is loosely coupled. This is what we strive to achieve with architectures on AWS. And this brings me to two AWS services that can assist in this regard. Amazon Simple Queue Service or SQS, and Amazon Simple Notification Service or SNS. But before I dive into those two services, let me just order a to go coffee on our cafe website. [SOUND] Done. All right, well, that's great. I should get a message when that order is ready. First up, let's discuss Amazon SQS. SQS allows you to send, store, and receive messages between software components at any volume. This is without losing messages or requiring other services to be available. Think of messages as our coffee orders, and the order board as an SQS queue. Messages have the person's name, coffee order, and time they ordered. The data contained within their message is called a payload, and it's protected until delivery. SQS queues are where messages are placed until they are processed, and AWS manages the underlying infrastructure for you to host those queues. These scale automatically are reliable and are easy to configure and use. Now, Amazon SNS is similar in that it is used to send out messages to services, but it can also send out notifications to end users. It does this in a different way, called a publish/subscribe or pub/sub model. This means that you can create something called an SNS topic, which is just a channel for messages to be delivered. You then configure subscribers to that topic, and finally publish messages for those subscribers in practice. That means you can send one message to a topic which will then fan out to all the subscribers in a single go. These subscribers can also be endpoints such as SQS queues, AWS Lambda functions, and HTTPS or HTTP webhooks. Additionally, SNS can be used to fan out notification to end users using mobile push, SMS, and email. Taking this back to our coffee shop, we could send out a notification when a customer's order is ready. This could be a simple SMS to let them know to pick it up or even a mobile push up. [SOUND] In fact, it looks like my phone just received a message. Looks like my order is ready. See you soon.
