# REL 4. Como projetar interações em um sistema distribuído para evitar falhas?
Os sistemas distribuídos dependem de redes de comunicação para interconectar componentes, como servidores ou serviços. A workload deve operar de forma confiável, apesar da perda de dados ou da latência nessas redes. Os componentes do sistema distribuído devem operar de uma maneira que não afete negativamente outros componentes ou a workload. Essas práticas recomendadas evitam falhas e melhoram o tempo médio entre falhas (MTBF).
**Topics**
+ [
# REL04-BP01 Identificar qual tipo de sistema distribuído é necessário
](rel_prevent_interaction_failure_identify.md)
+ [
# REL04-BP02 Implementar dependências com acoplamento fraco
](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [
# REL04-BP03 Fazer um trabalho constante
](rel_prevent_interaction_failure_constant_work.md)
+ [
# REL04-BP04 Garantir a idempotência das operações de mutação
](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificar qual tipo de sistema distribuído é necessário
Os sistemas distribuídos podem ser síncronos, assíncronos ou em lote. Os sistemas síncronos devem processar solicitações o mais rápido possível e se comunicar uns com os outros fazendo chamadas síncronas de solicitação e resposta usando protocolos HTTP/S, REST ou de chamada de procedimento remoto (RPC). Os sistemas assíncronos se comunicam uns com os outros trocando dados de forma assíncrona por meio de um serviço intermediário sem acoplar sistemas individuais. Os sistemas em lote recebem um grande volume de dados de entrada, executam processos de dados automatizados sem intervenção humana e geram dados de saída.
**Resultado desejado**: crie uma workload que interaja efetivamente com dependências síncronas, assíncronas e em lote.
**Práticas comuns que devem ser evitadas:**
+ A workload espera indefinidamente por uma resposta de suas dependências, o que pode fazer com que os clientes da workload esgotem o tempo limite, sem saber se a solicitação foi recebida.
+ A workload usa uma cadeia de sistemas dependentes que chamam um ao outro de forma síncrona. Para que toda a cadeia tenha êxito, isso exige primeiro que cada sistema esteja disponível e consiga processar uma solicitação, possivelmente fragilizando o comportamento e a disponibilidade geral.
+ A workload comunica-se com as dependências de forma assíncrona e depende do conceito de entrega de mensagens garantida exatamente uma vez, quando muitas vezes ainda é possível receber mensagens duplicadas.
+ A workload não usa ferramentas adequadas de agendamento em lote e permite a execução simultânea do mesmo trabalho em lotes.
**Benefícios de implementar esta prática recomendada**: é comum que uma determinada workload implemente um ou mais estilos de comunicação entre síncrono, assíncrono e em lote. Essa prática recomendada ajuda você a identificar as diferentes vantagens e desvantagens associadas a cada estilo de comunicação para tornar a workload capaz de tolerar interrupções em qualquer uma das dependências.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
As seções a seguir contêm diretrizes de implementação gerais e específicas de cada tipo de dependência.
**Orientações gerais**
+ Certifique-se de que os objetivos de nível de serviço (SLOs) de performance e confiabilidade que suas dependências oferecem atendam aos requisitos de performance e confiabilidade da workload.
+ Use [serviços de observabilidade da AWS](https://aws.amazon.com/cloudops/monitoring-and-observability) para [monitorar os tempos de resposta e as taxas de erro](https://www.youtube.com/watch?v=or7uFFyHIX0) para garantir que sua dependência esteja fornecendo serviços nos níveis necessários para sua workload.
+ Identifique os possíveis desafios que a workload pode enfrentar ao se comunicar com as dependências. Os sistemas distribuídos [apresentam uma ampla variedade de desafios](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) que podem aumentar a complexidade arquitetônica, a carga operacional e o custo. Os desafios comuns são: latência, interrupções na rede, perda de dados, ajuste de escala e atraso na replicação de dados.
+ Implemente gerenciamento e [registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) de erros robustos para obter ajuda para solucionar problemas quando sua dependência apresentar problemas.
**Dependência síncrona**
Nas comunicações síncronas, a workload envia uma solicitação para a dependência e bloqueia a operação à espera de uma resposta. Quando a dependência recebe a solicitação, ela tenta tratá-la o mais rápido possível e envia uma resposta de volta à workload. Um desafio significativo da comunicação síncrona é que ela causa o acoplamento temporal, o que exige que a workload e as respectivas dependências estejam disponíveis ao mesmo tempo. Quando a workload precisar se comunicar de forma síncrona com as dependências, pense na seguinte orientação:
+ Sua workload não deve depender de várias dependências síncronas para realizar uma única função. Essa cadeia de dependências aumenta a fragilidade geral porque todas as dependências no caminho precisam estar disponíveis para que a solicitação seja concluída com êxito.
+ Quando uma dependência não estiver íntegra ou estiver indisponível, determine suas estratégias de tratamento de erros e de novas tentativas. Evite usar comportamento bimodal. O comportamento bimodal ocorre quando a workload exibe um comportamento diferente nos modos normal e de falha. Para obter mais detalhes sobre o comportamento bimodal, consulte [REL11-BP05 Usar estabilidade estática para evitar comportamento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html).
+ Lembre-se que antecipar-se à falha é melhor do que fazer a workload esperar. Por exemplo, o [Guia do desenvolvedor do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html) descreve como lidar com novas tentativas e falhas ao invocar funções do Lambda.
+ Defina tempos limite quando a workload chamar sua dependência. Essa técnica evita esperas muito longas ou indefinidas por uma resposta. Para ver uma discussão útil sobre esse problema, consulte [Ajustar as configurações de solicitação HTTP do AWS SDK Java para aplicações do Amazon DynamoDB com reconhecimento de latência](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/).
+ Minimize o número de chamadas feitas da workload para a dependência para atender a uma única solicitação. Ter chamadas interativas entre elas aumenta o acoplamento e a latência.
**Dependência assíncrona**
Para dissociar temporariamente a workload de sua dependência, elas devem se comunicar de forma assíncrona. Usando uma abordagem assíncrona, a workload pode continuar com qualquer outro processamento sem precisar esperar que a dependência, ou cadeia de dependências, envie uma resposta.
Quando a workload precisar se comunicar de forma assíncrona com a dependência, pense na seguinte orientação:
+ Determine se deseja usar mensagens ou streaming de eventos com base no caso de uso e requisitos. O [sistema de mensagens](https://aws.amazon.com/messaging/) permite que sua workload se comunique com sua dependência enviando e recebendo mensagens por meio de um agente de mensagens. O [streaming de eventos](https://aws.amazon.com/streaming-data/) permite que sua workload e sua dependência usem um serviço de streaming para publicar e assinar eventos, entregues como fluxos contínuos de dados, que precisam ser processados o mais rápido possível.
+ O sistema de mensagens e o streaming de eventos gerenciam as mensagens de forma diferente, então é necessário tomar decisões sobre concessão com base em:
+ **Prioridade da mensagem:** os agentes de mensagens podem processar mensagens de alta prioridade antes das mensagens normais. No streaming de eventos, todas as mensagens têm a mesma prioridade.
+ **Consumo de mensagens**: os agentes de mensagens garantem que os consumidores recebam a mensagem. Os consumidores de streaming de eventos devem rastrear a última mensagem que leram.
+ **Ordenação das mensagens**: com o sistema de mensagens, não é garantido receber mensagens na ordem exata em que elas são enviadas, a menos que você use a abordagem FIFO (primeira a entrar, primeira a sair). O streaming de eventos sempre preserva a ordem na qual os dados foram produzidos.
+ **Exclusão de mensagens**: com o sistema de mensagens, o consumidor deve excluir a mensagem após processá-la. O serviço de streaming de eventos anexa a mensagem a um fluxo e permanece lá até que o período de retenção da mensagem expire. Essa política de exclusão torna o streaming de eventos adequado para reproduzir mensagens.
+ Defina como a workload sabe quando a dependência conclui o trabalho. Por exemplo, quando sua workload invoca uma [função do Lambda de forma assíncrona](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html), o Lambda coloca o evento em uma fila e retorna uma resposta informando êxito, sem informações adicionais. Após a conclusão do processamento, a função do Lambda pode [enviar o resultado para um destino](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-destinations), configurável com base no sucesso ou na falha.
+ Crie a workload para lidar com mensagens duplicadas utilizando a idempotência. Idempotência significa que os resultados da workload não mudam, mesmo que ela seja gerada mais de uma vez para a mesma mensagem. É importante ressaltar que os serviços de [mensagens](https://aws.amazon.com/sqs/faqs/#FIFO_queues) ou [streaming](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) reenviarão uma mensagem se ocorrer uma falha na rede ou se uma confirmação não for recebida.
+ Se a workload não receber uma resposta da dependência, ela precisará reenviar a solicitação. Considere limitar o número de novas tentativas para preservar a CPU, a memória e os recursos de rede da workload para lidar com outras solicitações. A [documentação do AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) mostra como lidar com erros de invocação assíncrona.
+ Utilize as ferramentas adequadas de observabilidade, depuração e rastreamento para gerenciar e operar a comunicação assíncrona da workload com a dependência. É possível usar o [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) para monitorar serviços de [mensagens](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) e [streaming de eventos](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html). Você também pode instrumentar sua workload com o [AWS X-Ray](https://aws.amazon.com/xray/) para [obter insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html) rapidamente para solucionar problemas.
**Dependência de lote**
Os sistemas em lote utilizam dados de entrada, iniciam uma série de trabalhos para processá-los e produzem alguns dados de saída, sem intervenção manual. Dependendo do tamanho dos dados, os trabalhos podem ser executados de minutos a, em alguns casos, vários dias. Quando a workload se comunica com a dependência em lote, pense na seguinte orientação:
+ Defina a janela de tempo em que a workload deve executar o trabalho em lote. A workload pode configurar um padrão de recorrência para invocar um sistema em lote, por exemplo, a cada hora ou no final de cada mês.
+ Determine a localização da entrada de dados e da saída de dados processados. Escolha um serviço de armazenamento, como o [Amazon Simple Storage Services (Amazon S3)](https://aws.amazon.com/s3/), o [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) e o [Amazon](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) FSx para Lustre, que permita que sua workload leia e grave arquivos em grande escala.
+ Se sua workload precisar invocar vários trabalhos em lote, você poderá usar o [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc) para simplificar a orquestração de trabalhos em lote executados na AWS ou on-premises. Este [projeto de exemplo](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app) demonstra a orquestração de trabalhos em lote usando Step Functions, o [AWS Batch](https://aws.amazon.com/batch/) e o Lambda.
+ Monitore trabalhos em lote para procurar anormalidades, como um trabalho que leva mais tempo do que deveria para ser concluído. Você pode usar ferramentas como o [CloudWatch Container Insights](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html) para monitorar ambientes e trabalhos em AWS Batch. Nesse caso, a workload impediria o início do próximo trabalho e informaria a equipe relevante sobre a exceção.
## Recursos
**Documentos relacionados:**
+ [Operações da Nuvem AWS: monitoramento e observabilidade](https://aws.amazon.com/cloudops/monitoring-and-observability)
+ [Amazon Builders' Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [REL11-BP05 Usar estabilidade estática para evitar comportamento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [Guia do desenvolvedor do AWS Lambda: tratamento de erros e novas tentativas automáticas no AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)
+ [Ajustar as configurações de solicitação HTTP do AWS SDK Java para aplicações do Amazon DynamoDB com reconhecimento de latência](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/)
+ [Sistema de mensagens da AWS](https://aws.amazon.com/messaging/)
+ [O que é streaming de dados?](https://aws.amazon.com/streaming-data/)
+ [Guia do desenvolvedor do AWS Lambda: invocação assíncrona](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html)
+ [Perguntas frequentes do Amazon Simple Queue Service: filas FIFO](https://aws.amazon.com/sqs/faqs/#FIFO_queues)
+ [Guia do desenvolvedor do Amazon Kinesis Data Streams: tratar registros duplicados](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html)
+ [Guia do desenvolvedor do Amazon Simple Queue Service: métricas do CloudWatch disponíveis para Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)
+ [Guia do desenvolvedor do Amazon Kinesis Data Streams: monitorar o serviço Amazon Kinesis Data Streams com o Amazon CloudWatch](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html)
+ [Guia do desenvolvedor do AWS X-Ray: conceitos do AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html)
+ [Exemplos da AWS no GitHub: AWS Step functions Complex Orchestrator App](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app)
+ [Guia do usuário do AWS Batch: AWS Batch CloudWatch Container Insights](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html)
**Vídeos relacionados:**
+ [AWS Summit SF 2022: Observabilidade full-stack e monitoramento de aplicações com a AWS (COP310)](https://www.youtube.com/watch?v=or7uFFyHIX0)
**Ferramentas relacionadas:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
+ [Amazon FSx para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc)
+ [AWS Batch](https://aws.amazon.com/batch/)
# REL04-BP02 Implementar dependências com acoplamento fraco
As dependências, como sistemas de enfileiramento, sistemas de streaming, fluxos de trabalho e balanceadores de carga, têm acoplamento fraco. O acoplamento fraco ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade.
Dependências de desacoplamento, como sistemas de filas, sistemas de streaming e fluxos de trabalho, ajudam a minimizar o impacto de alterações ou falhas em um sistema. Essa separação impede o comportamento de um componente de afetar outros que dependem dele, melhorando a resiliência e a agilidade.
Em sistemas fortemente acoplados, alterações em um componente podem exigir mudanças em outros componentes que dependem dele, o que resulta em performance degradada em todos eles. O acoplamento *fraco* interrompe essa dependência para que os componentes dependentes só precisem saber a interface versionada e publicada. A implementação de um acoplamento fraco entre dependências isola uma falha em uma dependência para não afetar a outra.
O acoplamento fraco permite modificar o código ou adicionar recursos a um componente, minimizando o risco para outros componentes que dependem dele. Ele também permite resiliência granular em nível de componente, caso em que é possível aumentar a escala horizontalmente ou até mesmo alterar a implementação subjacente da dependência.
Para melhorar ainda mais a resiliência por meio do acoplamento fraco, torne as interações de componentes assíncronas sempre que possível. Esse modelo é adequado para qualquer interação que não precise de uma resposta imediata e em que uma confirmação de que uma solicitação foi registrada será suficiente. Envolve um componente que gera eventos e outro que os consome. Os dois componentes não se integram por meio de interação direta ponto a ponto, mas geralmente por meio de uma camada de armazenamento durável intermediária, como uma fila do Amazon SQS, uma plataforma de dados de streaming, como o Amazon Kinesis, ou o AWS Step Functions.
![\[Diagrama que mostra que dependências como sistemas de enfileiramento e balanceadores de carga têm acoplamento fraco\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/framework/images/dependency-diagram.png)
As filas do Amazon SQS e os AWS Step Functions são apenas duas maneiras de adicionar uma camada intermediária para acoplamento fraco. As arquiteturas orientadas a eventos também podem ser criadas na Nuvem AWS com o Amazon EventBridge, que pode abstrair clientes (produtores de eventos) dos serviços dos quais eles dependem (consumidores de eventos). O Amazon Simple Notification Service (Amazon SNS) é uma solução eficaz quando você precisa de mensagens de alto throughput, baseadas em push e muitos para muitos. Usando tópicos do Amazon SNS, seus sistemas de publicadores podem enviar mensagens para um grande número de endpoints assinantes para processamento paralelo.
Embora as filas ofereçam várias vantagens, na maioria dos sistemas complexos em tempo real, as solicitações mais antigas do que um tempo limite (geralmente segundos) devem ser consideradas obsoletas (o cliente desistiu e não está mais esperando por uma resposta) e não devem ser processadas. Dessa forma, as solicitações mais recentes (e provavelmente ainda válidas) podem ser processadas.
**Resultado desejado:** a implementação de dependências com acoplamento fraco permite minimizar a área de superfície de falha em um nível de componente, o que ajuda a diagnosticar e resolver problemas. Ela também simplifica os ciclos de desenvolvimento, permitindo que as equipes implementem mudanças em um nível modular sem impactar a performance de outros componentes que dependem delas. Essa abordagem fornece a capacidade de aumentar a escala horizontalmente em nível de componente com base nas necessidades dos recursos, bem como na utilização de um componente que contribui para a redução de custos.
**Práticas comuns que devem ser evitadas:**
+ Implantar uma workload monolítica.
+ Invocar diretamente as APIs entre níveis de workload sem recurso de failover ou processamento assíncrono da solicitação.
+ Acoplamento forte usando dados compartilhados. Sistemas com acoplamento fraco devem evitar o compartilhamento de dados por meio de bancos de dados compartilhados ou outras formas de armazenamento de dados com acoplamento forte, o que pode reintroduzir o acoplamento forte e impedir a escalabilidade.
+ Ignorar a pressão contrária. A workload deve ter a capacidade de diminuir ou interromper a entrada de dados quando um componente não puder processá-los na mesma velocidade.
**Benefícios de implementar esta prática recomendada:** o acoplamento fraco ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade. Uma falha em um componente é isolada dos demais.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto
## Orientação para implementação
Implemente dependências com acoplamento fraco. Existem várias soluções que permitem criar aplicações com acoplamento fraco. Isso inclui serviços para implementar filas totalmente gerenciadas, fluxos de trabalho automatizados, reação a eventos e APIs, entre outros, que podem ajudar a isolar o comportamento de componentes de outros componentes e, dessa forma, aumentar a resiliência e a agilidade.
+ **Crie arquiteturas orientadas a eventos:** o [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) ajuda você a criar arquiteturas orientadas a eventos distribuídas e com acoplamento fraco.
+ **Implemente filas em sistemas distribuídos:** é possível usar o [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) para integrar e desacoplar sistemas distribuídos.
+ **Containerize componentes na forma de microsserviços:** os [microsserviços](https://aws.amazon.com/microservices/) permitem que as equipes criem aplicações formadas por pequenos componentes independentes que se comunicam por meio de APIs bem definidas. O [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) e o [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) podem ajudar você a começar a usar contêineres mais rápido.
+ **Gerencie fluxos de trabalho com Step Functions:** o [Step Functions](https://aws.amazon.com/step-functions/getting-started/) ajuda você a coordenar vários serviços da AWS em fluxos de trabalho flexíveis.
+ **Utilize as arquiteturas de mensagens publicador-assinante (pub/sub):** o [Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) fornece entrega de mensagens de publicadores para assinantes (também conhecidos como produtores e consumidores).
### Etapas de implementação
+ Os componentes em uma arquitetura orientada a eventos são iniciados por eventos. Eventos são ações que ocorrem em um sistema, como um usuário que adiciona um item a um carrinho. Quando uma ação é bem-sucedida, um evento que aciona o próximo componente do sistema é gerado.
+ [Criar aplicações orientadas por eventos com o Amazon EventBridge](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [AWS re:Invent 2022: Desenvolver integrações orientadas por eventos com o Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ Os sistemas de mensagens distribuídos têm três partes principais que precisam ser implementadas para uma arquitetura baseada em fila. Eles incluem componentes do sistema distribuído, a fila usada para desacoplamento (distribuída em servidores do Amazon SQS) e as mensagens na fila. Um sistema típico tem produtores que iniciam a mensagem na fila e o consumidor que recebe a mensagem da fila. A fila armazena as mensagens em vários servidores do Amazon SQS para fins de redundância.
+ [Arquitetura básica do Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [Envie mensagens entre aplicações distribuídas com o Amazon Simple Queue Service](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+ Os microsserviços, quando bem utilizados, melhoram a capacidade de manutenção e aumentam a escalabilidade, pois os componentes com acoplamento fraco são gerenciados por equipes independentes. Isso também permite o isolamento de comportamentos em um único componente em caso de alterações.
+ [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [Vamos arquitetar\$1 Arquitetar microsserviços com contêineres](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+ Com o AWS Step Functions é possível criar aplicações distribuídas, automatizar processos, orquestrar microsserviços, entre outras coisas. A orquestração de vários componentes em um fluxo de trabalho automatizado permite desacoplar as dependências na aplicação.
+ [Criar um fluxo de trabalho sem servidor com o AWS Step Functions e o AWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
+ [Conceitos básicos do AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantia da idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [O que é o Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [O que é o Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [Romper com seu monólito](https://pages.awscloud.com/break-up-your-monolith.html)
+ [Organizar microsserviços baseados em filas com o AWS Step Functions e o Amazon SQS](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [Arquitetura básica do Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [Arquitetura baseada em fila](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Introdução a arquiteturas orientadas por eventos e ao Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Fechar loops e abrir mentes: como assumir o controle de sistemas grandes e pequenos ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Migrar para arquiteturas orientadas por eventos (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Aplicações sem servidor orientadas por eventos e escaláveis usando o Amazon SQS e o Lambda](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022: Desenvolver integrações orientadas por eventos com o Amazon EventBridge](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017: Mergulho profundo e práticas recomendadas do Elastic Load Balancing](https://www.youtube.com/watch?v=9TwkMMogojY)
# REL04-BP03 Fazer um trabalho constante
Os sistemas podem falhar quando há alterações grandes e rápidas na carga. Por exemplo, se a sua workload está realizando uma verificação de integridade que monitora a integridade de milhares de servidores, ela deve sempre enviar a carga útil com o mesmo tamanho (um snapshot completo do estado atual). Independentemente de nenhum servidor falhar ou todos eles, o sistema de verificação de integridade está realizando um trabalho constante sem alterações grandes e rápidas.
Por exemplo, se o sistema de verificação de integridade estiver monitorando 100 mil servidores, a carga nele será nominal a uma taxa de falha do servidor normalmente leve. No entanto, se um evento importante deixar metade desses servidores com problemas de integridade, o sistema de verificação de integridade ficará sobrecarregado tentando atualizar os sistemas de notificação e comunicar o estado com seus clientes. Portanto, em vez disso, o sistema de verificação de integridade deve enviar o snapshot completo do estado atual a cada vez. 100.000 estados de integridade do servidor, cada um representado por um bit, seriam apenas uma carga útil de 12,5 KB. Independentemente de nenhum servidor ou falhar, ou se todos eles falharem, o sistema de verificação de integridade está realizando um trabalho constante, e alterações grandes e rápidas não são uma ameaça para a estabilidade do sistema. Na verdade, é assim que o Amazon Route 53 lida com verificações de integridade de endpoints (como endereços IP) para determinar como os usuários finais são roteados para eles.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Baixo
## Orientação para implementação
+ Faça um trabalho constante para que os sistemas não falhem quando houver mudanças rápidas e grandes na carga.
+ Implemente dependências com acoplamento fraco. As dependências, como sistemas de enfileiramento, sistemas de streaming, fluxos de trabalho e balanceadores de carga, têm acoplamento fraco. O acoplamento fraco ajuda a isolar o comportamento de um componente de outros componentes que dependem dele, aumentando a resiliência e a agilidade.
+ [Amazon Builders' Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Fechar loops e abrir mentes: como assumir o controle de sistemas grandes e pequenos ARC337 (inclui trabalho constante)](https://youtu.be/O8xLxNje30M?t=2482)
+ Para o exemplo de um sistema de verificação de integridade monitorando 100.000 servidores, crie workloads para que os tamanhos das cargas permaneçam constantes, independentemente do número de sucessos ou falhas.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantia da idempotência](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Introdução a arquiteturas orientadas por eventos e ao Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Fechar loops e abrir mentes: como assumir o controle de sistemas grandes e pequenos ARC337 (inclui trabalho constante)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Fechar loops e abrir mentes: como assumir o controle de sistemas grandes e pequenos ARC337 (inclui acoplamento fraco, trabalho constante, estabilidade estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Migrar para arquiteturas orientadas por eventos (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Garantir a idempotência das operações de mutação
Um serviço idempotente garante que cada solicitação seja processada exatamente uma vez, de modo que fazer várias solicitações idênticas tenha o mesmo efeito que uma única solicitação. Isso facilita para um cliente implementar novas tentativas sem o receio de que uma solicitação seja processada erroneamente várias vezes. Para fazer isso, os clientes podem emitir solicitações de API com um token de idempotência, que é usado sempre que a solicitação é repetida. Uma API de serviço idempotente usa o token para retornar uma resposta idêntica à resposta que foi retornada na primeira vez que a solicitação foi concluída, mesmo se o estado subjacente do sistema tiver mudado.
Em um sistema distribuído, é relativamente fácil executar uma ação no máximo uma vez (o cliente faz apenas uma solicitação) ou pelo menos uma vez (continue solicitando até o cliente receber a confirmação do sucesso). Mas é difícil garantir que uma ação seja realizada *exatamente uma vez*, de modo que fazer várias solicitações idênticas tem o mesmo efeito que fazer uma única solicitação. Usando tokens de idempotência em APIs, os serviços podem receber uma solicitação mutante uma vez ou mais sem necessidade de criar registros duplicados nem efeitos colaterais.
**Resultado desejado:** você tem uma abordagem consistente, bem documentada e amplamente adotada para garantir a idempotência em todos os componentes e serviços.
**Práticas comuns que devem ser evitadas:**
+ Aplicar a idempotência indiscriminadamente, mesmo quando não é necessária.
+ Introduzir uma lógica excessivamente complexa para implementar a idempotência.
+ Usar carimbos de data/hora como chaves para a idempotência. Isso pode causar imprecisões devido à distorção do relógio ou devido a vários clientes que usam os mesmos carimbos de data/hora para aplicar as alterações.
+ Armazenar cargas úteis inteiras para fins de idempotência. Nessa abordagem, você salva cargas úteis de dados completas para cada solicitação e as substitui a cada nova solicitação. Isso pode degradar o desempenho e afetar a escalabilidade.
+ Gerar chaves de maneira inconsistente nos serviços. Sem chaves consistentes, os serviços podem não reconhecer solicitações duplicadas, o que gera resultados indesejados.
**Benefícios de implementar essa prática recomendada:**
+ Maior escalabilidade: o sistema pode lidar com novas tentativas e solicitações duplicadas sem precisar executar lógica adicional ou gerenciamento complexo de estados.
+ Confiabilidade aprimorada: a idempotência ajuda os serviços a lidar com várias solicitações idênticas de maneira consistente, o que reduz o risco de efeitos colaterais indesejados ou registros duplicados. Isso é especialmente crucial em sistemas distribuídos, onde falhas e novas tentativas de rede são comuns.
+ Consistência de dados aprimorada: como a mesma solicitação produz a mesma resposta, a idempotência ajuda a manter a consistência dos dados em sistemas distribuídos. Isso é essencial para manter a integridade das transações e operações.
+ Tratamento de erros: os tokens de idempotência tornam o tratamento de erros mais simples. Se um cliente não receber uma resposta devido a um problema, ele poderá reenviar a solicitação com segurança com o mesmo token de idempotência.
+ Transparência operacional: a idempotência permite um melhor monitoramento e registro. Os serviços podem registrar solicitações com seus tokens de idempotência, o que facilita o rastreamento e a depuração de problemas.
+ Contrato de API simplificado: ele pode simplificar o contrato entre os sistemas do lado do cliente e do servidor e reduzir o medo de processamento incorreto de dados.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Em um sistema distribuído, é relativamente fácil executar uma ação no máximo uma vez (o cliente faz apenas uma solicitação) ou pelo menos uma vez (o cliente continua solicitando até a confirmação do sucesso). No entanto, é difícil implementar um comportamento do tipo *exatamente uma vez*. Para conseguir isso, os clientes devem gerar e fornecer um token de idempotência para cada solicitação.
Ao usar tokens de idempotência, um serviço pode distinguir entre solicitações novas e repetidas. Quando um serviço recebe uma solicitação com um token de idempotência, ele verifica se o token já foi usado. Se o token tiver sido usado, o serviço recuperará e retornará a resposta armazenada. Se o token for novo, o serviço processará a solicitação, armazenará a resposta junto com o token e, em seguida, retornará a resposta. Esse mecanismo torna todas as respostas idempotentes, o que aumenta a confiabilidade e a consistência do sistema distribuído.
A idempotência também é um comportamento importante das arquiteturas orientadas por eventos. Essas arquiteturas geralmente são apoiadas por uma fila de mensagens, como Amazon SQS, Amazon MQ, Amazon Kinesis Streams ou Amazon Managed Streaming for Apache Kafka (MSK). Em algumas circunstâncias, uma mensagem publicada somente uma vez pode ser entregue acidentalmente mais de uma vez. Quando um publicador gera e inclui tokens de idempotência nas mensagens, ele solicita que o processamento de qualquer mensagem duplicada recebida não resulte em uma ação repetida para a mesma mensagem. Os consumidores devem acompanhar cada token recebido e ignorar as mensagens que contêm tokens duplicados.
Os serviços e os consumidores também devem passar o token de idempotência recebido para qualquer serviço downstream que ele chame. Cada serviço downstream na cadeia de processamento é igualmente responsável por garantir que a idempotência seja implementada para evitar o efeito colateral de processar uma mensagem mais de uma vez.
### Etapas de implementação
1. **Identifique operações idempotentes**
Determine quais operações exigem idempotência. Elas geralmente incluem métodos HTTP POST, PUT e DELETE e operações de inserção, atualização ou exclusão do banco de dados. Operações que não alteram o estado, como consultas somente leitura, geralmente não exigem idempotência, a menos que tenham efeitos colaterais.
1. **Usar identificadores exclusivos**
Inclua um token exclusivo em cada solicitação de operação de idempotência enviada pelo remetente, diretamente na solicitação ou como parte dos metadados (por exemplo, um cabeçalho HTTP). Isso permite que o destinatário reconheça e manipule solicitações ou operações duplicadas. Os identificadores comumente usados para tokens incluem [Universally Unique Identifiers (UUIDs)](https://datatracker.ietf.org/doc/html/rfc9562) e [K-Sortable Unique Identifiers (KSUIDs)](https://github.com/segmentio/ksuid).
1. **Rastreie e gerencie o estado**
Mantenha o estado de cada operação ou solicitação na workload. Isso pode ser feito armazenando o token de idempotência e o estado correspondente (como pendente, concluído ou com falha) em um banco de dados, cache ou outro armazenamento persistente. Essas informações de estado permitem que a workload identifique e processe solicitações ou operações duplicadas.
Mantenha a consistência e a atomicidade usando mecanismos de controle de concorrência apropriados, se necessário, como bloqueios, transações ou controles de simultaneidade otimistas. Isso inclui o processo de registrar o token de idempotência e executar todas as operações de mutação associadas ao atendimento da solicitação. Isso ajuda a evitar condições de corrida e verifica se as operações de idempotência são executadas corretamente.
Remova regularmente os tokens de idempotência antigos do datastore para gerenciar o armazenamento e o desempenho. Se o sistema de armazenamento oferecer suporte a isso, considere usar carimbos de data/hora de expiração para os dados (geralmente conhecidos como valores de vida útil, ou TTL). A probabilidade de reutilização do token de idempotência diminui com o tempo.
As opções de armazenamento da AWS normalmente usadas para armazenar tokens de idempotência e estados relacionados incluem:
+ **Amazon DynamoDB**: o DynamoDB é um serviço de banco de dados NoSQL que fornece desempenho de baixa latência e alta disponibilidade, o que o torna adequado para o armazenamento de dados relacionados à idempotência. O modelo de dados de documentos e valores-chave do DynamoDB permite o armazenamento e a recuperação eficientes dos tokens de idempotência e das informações de estado associadas. O DynamoDB também pode expirar automaticamente os tokens de idempotência se a aplicação definir um valor de TTL ao inseri-los.
+ **Amazon ElastiCache**: o ElastiCache pode armazenar tokens de idempotência com alto throughput, baixa latência e baixo custo. Tanto o ElastiCache (Redis) quanto o ElastiCache (Memcached) também podem expirar automaticamente os tokens de idempotência se a aplicação definir um valor de TTL ao inseri-los.
+ **Amazon Relational Database Service (RDS):** você pode usar o Amazon RDS para armazenar tokens de idempotência e informações de estado relacionadas, especialmente se a aplicação já usa um banco de dados relacional para outros fins.
+ **Amazon Simple Storage Service (S3):** o Amazon S3 é um serviço de armazenamento de objetos altamente escalável e durável que pode ser usado para armazenar tokens de idempotência e metadados relacionados. Os recursos de versionamento do S3 podem ser particularmente úteis para a manutenção do estado das operações de idempotência. A escolha do serviço de armazenamento geralmente depende de fatores como o volume de dados relacionados à idempotência, as características de desempenho necessárias, a necessidade de durabilidade e disponibilidade e como o mecanismo de idempotência se integra à arquitetura geral da workload.
1. **Implemente operações de idempotência**
Projete os componentes de API e workload para serem idempotentes. Incorpore verificações de idempotência nos componentes de workload. Antes de processar uma solicitação ou realizar uma operação, verifique se o identificador exclusivo já foi processado. Se já tiver sido processado, retorne o resultado anterior em vez de executar a operação novamente. Por exemplo, se um cliente enviar uma solicitação para criar um usuário, verifique se já existe um usuário com o mesmo identificador exclusivo. Se o usuário existir, deverão ser retornadas as informações do usuário existente em vez de criar outro. Da mesma forma, se um consumidor da fila receber uma mensagem com um token de idempotência duplicado, ele deverá ignorá-la.
Crie conjuntos de testes abrangentes que validem a idempotência das solicitações. Eles devem abranger uma ampla variedade de cenários, como solicitações bem-sucedidas, solicitações malsucedidas e solicitações duplicadas.
Se a workload utilizar funções do AWS Lambda, considere o Powertools para AWS Lambda. O Powertools for AWS Lambda é um kit de ferramentas para desenvolvedores para implementar as práticas recomendadas da tecnologia sem servidor e aumentar a velocidade do desenvolvedor ao trabalhar com funções do AWS Lambda. Em particular, ele fornece um utilitário para converter funções do Lambda em operações de idempotência que podem ser repetidas com segurança.
1. **Comunique a idempotência com clareza**
Documente a API e os componentes da workload para comunicar claramente a natureza de idempotência das operações. Isso ajuda os clientes a entender o comportamento esperado e a interagir com a workload de forma confiável.
1. **Monitore e audite**
Implemente mecanismos de monitoramento e auditoria para detectar quaisquer problemas relacionados à idempotência das respostas, como variações inesperadas de respostas ou tratamento excessivo de solicitações duplicadas. Isso pode ajudar você a detectar e investigar quaisquer problemas ou comportamentos inesperados na workload.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL05-BP03 Controlar e limitar chamadas de novas tentativas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html)
+ [REL06-BP01 Monitorar todos os componentes da workload (geração)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Enviar notificações (processamento e emissão de alarmes em tempo real)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL08-BP02 Integrar testes funcionais como parte da sua implantação](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_functional_testing.html)
**Documentos relacionados:**
+ [Amazon Builders' Library: Como tornar as novas tentativas seguras com APIs idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
+ [Amazon Builders' Library: desafios com sistemas distribuídos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: confiabilidade, trabalho constante e uma boa xícara de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Amazon Elastic Container Service: Ensuring idempotency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/ECS_Idempotency.html)
+ [Como faço para tornar minha função do Lambda idempotente?](https://repost.aws/knowledge-center/lambda-function-idempotent)
+ [Ensuring idempotency in Amazon EC2 API requests](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html)
**Vídeos relacionados:**
+ [Building Distributed Applications with Event-driven Architecture - AWS Online Tech Talks](https://www.youtube.com/watch?v=gA2-eqDVSng&t=1668s)
+ [AWS re:Invent 2023 - Building next-generation applications with event-driven architecture](https://www.youtube.com/watch?v=KXR17uwLEC8)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems](https://www.youtube.com/watch?v=FGKGdUiZKto)
+ [AWS re:Invent 2023 - Advanced event-driven patterns with Amazon EventBridge](https://www.youtube.com/watch?v=6X4lSPkn4ps)
+ [AWS re:Invent 2018 - Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019 - Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
**Ferramentas relacionadas:**
+ [Idempotência com AWS Lambda Powertools (Java)](https://docs.powertools.aws.dev/lambda/java/utilities/idempotency/)
+ [Idempotência com AWS Lambda Powertools (Python)](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)
+ [Página do AWS Lambda Powertools no GitHub](https://github.com/aws-powertools/)