Desacoplamento e mensageria

Pontos-chave

• Standard vs FIFO: a standard tem vazão quase ilimitada, entrega pelo menos uma vez e ordem de melhor esforço. A FIFO mantém a ordem dentro de cada MessageGroupId e descarta duplicatas enviadas dentro de um intervalo de deduplicação de 5 minutos, com 300 chamadas por segundo por ação (3.000 mensagens por segundo em lotes de 10), mais no modo de alta vazão.
• Visibility timeout: a mensagem recebida fica oculta por 30 segundos por padrão (de 0 segundo a 12 horas). Se o consumidor não apagá-la a tempo, ela reaparece e é processada de novo, então ajuste acima do tempo de processamento.
• Retenção e tamanho: mensagens ficam 4 dias por padrão, de 1 minuto a 14 dias. Cada mensagem tem no máximo 1 MiB, e cargas maiores vão para o S3 com a Extended Client Library.
• Long polling: WaitTimeSeconds de até 20 segundos reduz respostas vazias e custo. Filas com atraso adiam a entrega em até 15 minutos.
• Dead-letter queue: depois de maxReceiveCount recebimentos (1 a 1.000) a mensagem vai para uma DLQ do mesmo tipo, na mesma conta e Região. Filas standard mantêm o horário original de entrada, então dê à DLQ uma retenção maior.
• Escalar workers: escale um grupo do Auto Scaling pelo backlog por instância (ApproximateNumberOfMessages dividido pelas instâncias em serviço). Mensagens de uma instância encerrada voltam para a fila.

Pontos-chave

• Assinantes: filas SQS, funções Lambda, Amazon Data Firehose e endpoints HTTP/S, além de e-mail, SMS e push para pessoas.
• Fan-out: um tópico com várias filas SQS assinadas, cada uma consumida pelo seu serviço. Um consumidor lento nunca atrasa os outros e suas mensagens esperam na fila dele.
• Filtro de mensagens: uma filter policy na assinatura, aplicada aos atributos ou ao corpo da mensagem, entrega a esse assinante só o que combina.
• Tópicos FIFO: ordem estrita e deduplicação, entregues apenas a filas SQS FIFO ou standard. E-mail, SMS, push e HTTP/S não podem assinar um tópico FIFO.

Pontos-chave

• Event bus e regras: a regra compara um event pattern e roteia para um ou mais destinos, com transformação opcional do evento. Feito para muitas origens e muitos destinos.
• Pipes: integração ponto a ponto de uma origem para um destino, com filtro e enriquecimento opcionais, por exemplo uma fila SQS enriquecida por um API destination e enviada ao Step Functions. Só os eventos que passam no filtro são cobrados.
• Scheduler: agendamentos serverless por cron, por intervalo ou de execução única, com janelas flexíveis e limite de tentativas.
• Archive e replay: guarda eventos (indefinidamente por padrão) e os reenvia ao bus de origem para corrigir erros ou testar novos consumidores.

Pontos-chave

• Standard: até 1 ano, execução exatamente uma vez, cobrado por transição de estado, histórico guardado por 90 dias. Serve para trabalho longo e não idempotente, como pagamentos.
• Express: até 5 minutos, cobrado por execuções, duração e memória. Pelo menos uma vez no modo assíncrono, no máximo uma vez no síncrono. Serve para alto volume de eventos e ingestão de IoT.
• Callbacks e jobs: só o Standard aceita os padrões .sync e .waitForTaskToken, por exemplo para esperar uma aprovação humana.
• Tipo fixo: o tipo do fluxo não muda depois que a máquina de estados é criada.

Pontos-chave

• Throttling: token bucket de 10.000 requisições por segundo com burst de 5.000 por conta por Região na maioria das Regiões. Acima disso o cliente recebe 429 Too Many Requests. Limites de stage, de método e de usage plan por cliente ficam abaixo dele.
• Cache: só em REST APIs, por stage, TTL de 300 segundos por padrão e até 3.600. Por padrão só métodos GET entram no cache.
• Timeout de integração: de 50 milissegundos a 29 segundos em REST APIs. APIs regionais e privadas podem aumentar, talvez com uma cota de throttling menor. Trabalhos longos ficam assíncronos com SQS ou Step Functions.
• Tipos de endpoint: edge-optimized, regional e privado. Edge-optimized e privado existem só para REST APIs.

Pontos-chave

• Protocolos: JMS, NMS, AMQP 0.9.1, AMQP 1.0, STOMP, MQTT e WebSocket.
• Alta disponibilidade: brokers ActiveMQ ativo/standby replicados entre Availability Zones, clusters RabbitMQ de 3 nós com quorum queues distribuídas entre AZs.
• Entre Regiões: a replicação entre Regiões do ActiveMQ copia mensagens de forma assíncrona para um broker réplica que pode ser promovido.
• Projetos novos: para aplicações novas na nuvem a AWS recomenda SQS e SNS.

Pontos-chave

• Shards: cada shard recebe até 1 MB por segundo ou 1.000 registros por segundo de escrita e entrega até 2 MB por segundo de leitura. O modo on-demand gerencia os shards, o provisionado cobra por shard-hora.
• Ordem: a partition key escolhe o shard e cada registro recebe um número de sequência nele, então registros relacionados mantêm a ordem.
• Retenção e replay: 24 horas por padrão, até 365 dias. Cada aplicação lê de forma independente e pode reler, ao contrário do SQS, em que a mensagem apagada some.
• Tamanho do registro: um blob de dados de até 1 MB.

Pontos-chave

• Sessão fora da instância: guarde sessões no Amazon ElastiCache ou no DynamoDB para que qualquer instância atenda qualquer requisição e o scale-in não perca nada.
• Sticky sessions: o ALB pode prender um cliente a um destino, mas uma sessão que existe só naquela instância se perde quando ela é encerrada.
• Arquivos compartilhados: uploads vão para o S3 ou o Amazon EFS, nunca para o disco local de uma instância.
• Horizontal antes de vertical: somar instâncias atrás de um load balancer escala sem o teto e sem a parada de redimensionar uma única instância.