We begin the chapter on messaging and events, the pieces that connect the different components of a modern architecture. The first and most fundamental is SQS (Simple Queue Service): AWS's queue service. We already mentioned it as a Lambda trigger (subchapter 14.2); now we'll understand it in depth.

Imagine an online store. When a customer places an order, you need to: charge, update inventory, send an email, notify the warehouse... If the service that receives the order had to do all that at once and wait for each step to finish, it would be slow and fragile: if the email service is down, does the entire order get lost?

The solution is to decouple the services with a queue in between. The order service just leaves a "message" ("process this order") in the queue and moves on. Other services pull messages from the queue and process them at their own pace.

A queue is like a shared to-do list. One service puts messages (tasks) in on one side, and another service takes them out and processes them on the other.

• Producer: the one who creates messages and puts them in the queue (e.g., the order service).
• Consumer: the one who takes messages out and processes them (e.g., a Lambda or a server).

Analogy: an SQS queue is like the order slip in a restaurant. The waiter (producer) writes down the orders and hangs them in the kitchen. The cooks (consumers) pick up the slips and prepare them at their own pace. The waiter doesn't wait in the kitchen: he leaves the slip and keeps serving tables. If many orders come in at once, they pile up and get done as time allows; nothing is lost.

The queue separates producer and consumer, which brings huge advantages:

• Resilience: if the consumer goes down, the messages wait in the queue without being lost. When it comes back, it processes them. The producer doesn't even notice.
• Peak smoothing: if a flood of messages arrives (Black Friday), the queue accumulates them and the consumer processes them at a sustainable pace, without being overwhelmed.
• Independent scaling: you can add more consumers to empty the queue faster, without touching the producer.

We'll dive deeper into this decoupling in subchapter 15.4.

SQS offers two types of queues, and choosing the right one is important.

This is the default queue. It prioritizes maximum throughput (handles huge amounts of messages). In exchange, it has two peculiarities you should know:

• No order guarantee: messages may be processed in a slightly different order than they arrived.
• "At least once" delivery: on rare occasions, a message could be delivered duplicated.

FIFO means "first in, first out." It guarantees two things that the standard queue does not:

• Strict order: messages are processed exactly in the order they arrived.
• No duplicates: each message is delivered exactly once.

In exchange, it has more limited throughput than the standard queue (though more than enough for most cases).

Examples to decide:

• Standard: resizing uploaded images. The order in which they're processed doesn't matter, and processing one twice isn't a big deal.
• FIFO: bank account operations. Order matters ("deposit 100" before "withdraw 50") and a duplicate would be a disaster (charging twice).

Practical rule: use standard by default; use FIFO only when order or avoiding duplicates are really important.

What happens if a message can't be processed? For example, it comes with corrupted data and the function fails every time it tries. Without protection, that message would be retried over and over, blocking the queue and wasting resources (a "poisoned message").

That's what the Dead Letter Queue (DLQ) is for, the "dead messages queue." You configure it so that, after a number of failed attempts (for example, 3), the problematic message is automatically moved to a separate queue:

This way, the problematic message stops blocking the main queue, but is not lost: it's saved in the DLQ so you can investigate it later.

Analogy: the DLQ is like the "problem orders" drawer in the kitchen. If an order slip is illegible or impossible to prepare, instead of blocking the cooks, it's set aside in that drawer for the manager to review later. The kitchen keeps running.

• SQS is AWS's queue service: a producer puts messages in and a consumer takes them out and processes them at their own pace.
• The queue decouples services: it provides resilience (messages wait if the consumer goes down), smooths peaks, and allows you to scale consumers independently.
• Standard queue: maximum throughput, but no guaranteed order and possible duplicates. It's the default option.
• FIFO queue: guarantees strict order and no duplicates, with more limited throughput. Use it when order or duplicates are critical (e.g., banking operations).
• The Dead Letter Queue (DLQ) collects messages that repeatedly fail, preventing them from blocking the queue without losing them, so you can review them later.

In the next subchapter we'll see the complement to queues: SNS, the notification service, which instead of "one to one" lets you send a message to many recipients at once.