AWS Event Services
SQS, SNS, EventBridge, Kinesis — quando usar cada um, idempotencia, DLQ e fan-out
Quatro servicos, quatro shapes diferentes. SQS = fila point-to-point. SNS = broadcast pub/sub. EventBridge = roteamento por payload. Kinesis = stream com replay. Misturar o errado e o desenho de sistema mais comum em entrevista.
Comparativo direto
| SQS | SNS | EventBridge | Kinesis | |
|---|---|---|---|---|
| Modelo | Queue | Topic (pub/sub) | Bus + rules | Append-only log |
| Padrao | Point-to-point | Fan-out | Content-based routing | Streaming + replay |
| Garantia | At-least-once (Standard); exactly-once (FIFO) | At-least-once | At-least-once | Ordered per partition |
| Retencao | 14 dias max | Nao retem (pass-through) | 24h por default | 7 dias (ate 365 paid) |
| Order | FIFO so com SQS FIFO + group ID | FIFO topics existem (mais raro) | Sem ordem | Por partition key |
| Replay | Nao (mensagem somente uma vez) | Nao | Archive + replay (paid) | Nativo |
| Filtragem | Nao (consumer filtra) | Subscription filter por atributo | Pattern por payload | Consumer filtra |
| Custo | Cheap | Cheap | ~3x SNS por evento | Por shard (caro se ocioso) |
| Quando | Tasks de worker, queue de jobs, decoupling | Fan-out simples para varios consumers | Roteamento complexo, integracoes 3rd-party SaaS | Analytics, audit, ML pipelines, sequencia importa |
Misturar e tao comum quanto criticavel:
- Usar Kinesis quando voce so precisa de SQS — paga shard caro sem motivo, complica consumer state
- Usar SNS direto para consumer unico — vira fan-out de 1, perde reentry/DLQ que SQS da de graca
- Usar SQS para evento com 5 consumidores — cada consumer apaga, ninguem mais ve. Use SNS → 5x SQS