O que são SQS e SNS para mensagens?

Question

Accepted Answer

**SQS** (Simple Queue Service) e **SNS** (Simple Notification Service) são serviços de mensagens AWS que permitem comunicação **desacoplada e assíncrona** entre componentes de aplicação. SQS é uma fila de mensagens (processamento um-para-um); SNS é pub/sub (broadcast um-para-muitos).

## SQS — filas de mensagens (desacoplamento, processamento assíncrono)

```text
SQS is a managed message QUEUE: producers send messages, consumers process them:
  → producer → [QUEUE] → consumer(s) process messages (at their own pace)
  → DECOUPLES components (producer doesn't wait for/depend on the consumer)
  → BUFFERS load (queue absorbs spikes; consumers process steadily)
  → RELIABLE (messages persist until processed; retries; dead-letter queues for failures)
  → SCALABLE (add more consumers to process faster)
→ Use for: async task processing, decoupling services, smoothing load spikes
```

## SNS — pub/sub (broadcast um-para-muitos)

```text
SNS is PUBLISH/SUBSCRIBE: publish a message to a TOPIC → ALL subscribers receive it:
  → publisher → [TOPIC] → fans out to MANY subscribers (one-to-many)
  → subscribers: SQS queues, Lambda functions, HTTP endpoints, email, SMS
  → use for: notifications, fan-out, broadcasting events to multiple consumers
```

## O padrão fan-out (SNS + SQS juntos)

```text
SNS topic → fans out to MULTIPLE SQS queues → each processed independently:
  Event → SNS topic → ┬→ SQS queue A → service A processes
                      ├→ SQS queue B → service B processes
                      └→ Lambda → does something else
→ One event triggers multiple independent processing pipelines (common architecture).
```

## Por que isso importa

Compreender SQS e SNS é valioso porque **mensagens assíncronas desacopladas são um padrão fundamental em arquiteturas escaláveis e resilientes**, e estes são os serviços de mensagens principais da AWS, então é conhecimento importante para arquitetura em nuvem. **SQS** (filas de mensagens) permite um padrão crucial: **desacoplar componentes** para que um produtor não dependa ou espere por um consumidor — produtores enviam mensagens para uma fila, e consumidores as processam em seu próprio ritmo, o que **buffer de carga** (a fila absorve picos de tráfego enquanto consumidores processam continuamente), oferece **confiabilidade** (mensagens persistem até serem processadas, com retentativas e dead-letter queues para falhas), e permite **escalabilidade** (adicionar consumidores para processar mais rápido).

Isso é essencial para processamento assíncrono de tarefas, desacoplamento de serviços e tratamento gracioso de carga variável. **SNS** (pub/sub) permite **broadcast um-para-muitos** — publicar uma mensagem em um tópico que se distribui para muitos assinantes (filas, funções Lambda, endpoints, email/SMS) — útil para notificações e broadcast de eventos para múltiplos consumidores.

Compreender o poderoso **padrão fan-out** (combinando SNS e SQS para que um evento dispare múltiplos pipelines de processamento independentes via SNS distribuindo para múltiplas filas SQS) reflete uma arquitetura comum e importante para sistemas event-driven.

Estes serviços e padrões são fundamentais para construir aplicações **fracamente acopladas, escaláveis e resilientes** — um princípio principal de uma boa arquitetura em nuvem (evitando acoplamento forte e dependências síncronas que criam fragilidade e gargalos).

Já que comunicação assíncrona desacoplada é fundamental para sistemas escaláveis e resilientes e SQS/SNS são os serviços primários da AWS para isso (com o padrão fan-out sendo uma arquitetura comum), compreender SQS e SNS é conhecimento valioso e praticamente importante da AWS para projetar aplicações em nuvem bem arquitetadas — blocos de construção chave para os padrões desacoplados, event-driven e assíncronos que tornam sistemas distribuídos escaláveis e robustos.