Amazon DVA-C02: Mensageria, Streaming e Arquiteturas Orientadas a Eventos (SNS, SQS, Kinesis, EventBridge, Step Functions) — Guia de estudos

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Faz parte do AWS Developer Associate DVA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Escolhendo a primitiva correta de mensageria e streaming

A escolha entre SNS, SQS (standard vs. FIFO), Kinesis, EventBridge e Step Functions começa com o padrão de comunicação: pub/sub, ponto a ponto, streaming ordenado, roteamento por barramento de eventos ou orquestração de workflows. O SNS é um publicador pub/sub com padrão fan-out; use Publish (chamada de SDK: Publish/PublishBatch) e inscreva endpoints SQS, Lambda, HTTP/S ou endpoints móveis. O SQS é um buffer durável ponto a ponto com semântica de ReceiveMessage/DeleteMessage; crie filas com CreateQueue e atributos como VisibilityTimeout, ReceiveMessageWaitTimeSeconds (long polling), MessageRetentionPeriod e políticas de redirecionamento (redrive policies) vinculando uma DLQ. Filas FIFO exigem FifoQueue=true e usam MessageGroupId mais MessageDeduplicationId (ou ContentBasedDeduplication) para ordenação e deduplicação. O Kinesis Data Streams é um serviço de streaming ordenado e baseado em shards; produtores chamam PutRecord/PutRecords e consumidores usam GetShardIterator (TRIM_HORIZON, LATEST, AT_SEQUENCE_NUMBER) e depois GetRecords. O Kinesis Firehose gerencia a entrega para o S3/Redshift/OpenSearch e oferece BufferingHints (SizeInMBs, IntervalInSeconds) e transformações com Lambda. O EventBridge roteia eventos com PutEvents e filtragem baseada em regras, suporta registro de esquemas (schema registry) e barramentos entre contas (cross-account buses). O Step Functions orquestra fluxos complexos; use StartExecution (Standard) ou StartSyncExecution para padrões Express síncronos, com integrações de Task como arn:aws:states:::lambda:invoke. Considere esses tradeoffs quando houver conflitos entre as necessidades de throughput, ordenação, garantias de entrega, retenção e orquestração.

• SNS: alto throughput em fan-out, sem ordenação, Publish/Subscribe, use MessageAttributes para roteamento.
• SQS Standard: entrega pelo menos uma vez (at-least-once), ordenação de melhor esforço (best-effort), long polling, mais barato para desacoplamento.
• SQS FIFO: ordenação exatamente uma vez (exactly-once) dentro de um MessageGroupId, use para ordenação estrita e deduplicação.
• Kinesis Data Streams: ordenado por shard, streaming de alto throughput, PutRecord/PutRecords, requer escalonamento de shards.
• Kinesis Firehose: entrega e buffer gerenciados, suporta criptografia no lado do servidor e transformações com Lambda.
• EventBridge: barramento de eventos com regras de roteamento, registro de esquemas, arquivamento e replay, API PutEvents.
• Step Functions: orquestração com estado (stateful), retries/Catch, tradeoffs entre Standard vs. Express para durabilidade e throughput.

Padrões de SQS e SNS, deduplicação e escalonamento de consumidores

Quando você precisa de desacoplamento durável, o SQS é a escolha ideal; implemente SendMessage/SendMessageBatch para os produtores e use ReceiveMessage com WaitTimeSeconds para habilitar o long polling e reduzir recebimentos vazios. Para ordenação estrita e deduplicação, crie uma fila FIFO com CreateQueue (FifoQueue=true) e defina o MessageGroupId para partições ordenadas; use o MessageDeduplicationId ou habilite o ContentBasedDeduplication para que payloads idênticos dentro da janela de deduplicação sejam suprimidos. Filas Standard podem entregar duplicatas — portanto, torne os consumidores idempotentes por meio de escritas condicionais no banco de dados (PutItem no DynamoDB com ConditionExpression attribute_not_exists(pk)) ou constraints de unicidade e upserts em transações no RDS. Configure políticas de redirecionamento (redrive policies) para rotear mensagens com falha para uma DLQ após o maxReceiveCount; monitore ApproximateNumberOfMessages e ApproximateNumberOfMessagesNotVisible via GetQueueAttributes. Integrações com Lambda usam CreateEventSourceMapping para SQS: defina BatchSize, MaximumBatchingWindowInSeconds e habilite FunctionResponseTypes = [“ReportBatchItemFailures”] para usar a semântica de resposta de lote parcial (partial-batch-response) e evitar o reprocessamento de registros bem-sucedidos. Cuidado com a semântica do Lambda com FIFO: a ordenação do grupo de mensagens impõe um processamento single-threaded por MessageGroupId, limitando a concorrência por grupo; escale particionando em muitos group IDs ou usando consumidores paralelos com SNS para múltiplas filas. Também preste atenção ao tempo limite de visibilidade (visibility timeout): use ChangeMessageVisibility quando o processamento demorar mais ou você corre o risco de processamento duplicado.

Kinesis Data Streams e Firehose: ordenação, retenção e tratamento de back-pressure

O Kinesis Data Streams fornece ordenação por shard e retenção durável para casos de uso de streaming. Produtores chamam PutRecord ou PutRecords (em lote) com uma PartitionKey que mapeia para um shard; consumidores chamam GetShardIterator e GetRecords, e então fazem o checkpoint dos offsets usando a KCL (Kinesis Client Library) ou uma tabela de checkpoint customizada no DynamoDB. A retenção padrão é de 24 horas (ajustável para janelas mais longas por configuração do stream, e recursos de retenção estendida onde disponíveis); planeje a contagem de shards com UpdateShardCount para corresponder ao throughput de escrita e ao paralelismo de leitura. O escalonamento de consumidores é restrito: um único mapeamento de fonte de eventos (event source mapping) do Lambda mapeia um shard para uma concorrência do Lambda, então aumente os shards para aumentar a concorrência de consumidores ou habilite o enhanced fan-out para dar a cada consumidor seu próprio canal de 2 MB/s e escalonamento independente usando a API SubscribeToShard (registro de consumidor). Use PutRecords para processamento em lote eficiente; o back-pressure surge quando os consumidores ficam para trás (Monitore GetRecords.IteratorAgeMilliseconds). Para lidar com picos, use buffer no Kinesis ou coloque um SQS na frente, use retries no produtor com exponential backoff e use criptografia no nível do stream com KMS para PII. O Kinesis Data Firehose simplifica a entrega: configure BufferingHints (SizeInMBs, IntervalInSeconds), CompressionFormat e uma transformação de dados com Lambda. O Firehose lida com retry/backoff para os destinos e pode gravar registros com falha em um bucket S3 de backup. Uma armadilha comum é o subprovisionamento de shards: os consumidores ficam sem dados (starve) e a latência aumenta; meça e escale proativamente.

← Bancos de Dados e Cache (RDS · Todos os domínios

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →