# Arquitetura da workload
<a name="workload-architecture"></a>

 Uma workload confiável começa com as decisões iniciais de projeto que envolvem tanto o software quanto a infraestrutura. Suas decisões de arquitetura afetarão o comportamento da workload em todos os cinco pilares do Well-Architected. Para atingir a confiabilidade, há padrões específicos que devem ser seguidos. 

 As seções a seguir explicam as práticas recomendadas a serem usadas com esses padrões para fins de confiabilidade.

**Topics**
+ [Projete a arquitetura de serviço da workload](design-your-workload-service-architecture.md)
+ [Projete as interações em um sistema distribuído para evitar falhas](design-interactions-in-a-distributed-system-to-prevent-failures.md)
+ [Projete as interações em um sistema distribuído para mitigar ou resistir a falhas](design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.md)

# Projete a arquitetura de serviço da workload
<a name="design-your-workload-service-architecture"></a>

 Use uma arquitetura orientada a serviços (SOA) ou uma arquitetura de microsserviços para criar workloads altamente escaláveis e confiáveis. A arquitetura orientada a serviços (SOA) é a prática de tornar componentes de software reutilizáveis por meio de interfaces de serviço. A arquitetura de microsserviços vai além para tornar os componentes menores e mais simples. 

 As interfaces de arquitetura orientada a serviços (SOA) usam padrões de comunicação comuns para que possam ser rapidamente incorporadas a novas workloads. A SOA substituiu a prática de construção de arquiteturas monolíticas, que consistiam em unidades interdependentes e indivisíveis. 

 Na AWS, sempre usamos a SOA, mas agora adotamos a criação de nossos sistemas usando microsserviços. Embora os microsserviços tenham várias qualidades interessantes, o principal benefício para disponibilidade é que eles são menores e mais simples. Eles permitem diferenciar a disponibilidade exigida de diferentes serviços e, portanto, concentrar os investimentos mais especificamente nos microsserviços que têm as maiores necessidades de disponibilidade. Por exemplo, para entregar páginas de informações do produto em Amazon.com ("páginas de detalhes"), centenas de microsserviços são invocados para criar partes separadas da página. Embora haja alguns microsserviços que precisem estar disponíveis para fornecer o preço e os detalhes do produto, a grande maioria do conteúdo na página poderá simplesmente ser excluída se o serviço não estiver disponível. Mesmo itens como fotos e avaliações não são necessários para proporcionar uma experiência em que o cliente possa comprar um produto. 

**Topics**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Criar serviços voltados para domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md)

# REL03-BP01 Escolher como segmentar a workload
<a name="rel_service_architecture_monolith_soa_microservice"></a>

 A segmentação de workloads é importante ao determinar os requisitos de resiliência da sua aplicação. Uma arquitetura monolítica deve ser evitada sempre que possível. Em vez disso, considere cuidadosamente quais componentes da aplicação podem ser distribuídos em microsserviços. Dependendo dos requisitos de sua aplicação, isso pode acabar sendo uma combinação de uma arquitetura orientada a serviços (SOA) com microsserviços sempre que possível. Workloads com capacidade para serem do tipo sem estado têm maior chance de ser implantadas como microsserviços. 

 **Resultado desejado:** as workloads devem ser compatíveis, escaláveis e o mais vagamente agrupadas possível. 

 Ao tomar decisões sobre como segmentar uma workload, pondere os benefícios e as complexidades. O que é ideal para um novo produto a caminho do seu primeiro lançamento não se aplica a uma workload que foi criada para ajuste de escala a partir das necessidades iniciais. Ao refatorar um monólito existente, será necessário considerar o quanto a aplicação poderá oferecer um bom suporte a uma decomposição em direção à condição sem estado. A divisão dos serviços em pedaços menores permite que equipes pequenas e bem definidas os desenvolvam e gerenciem. No entanto, serviços menores podem introduzir complexidades que incluem maior latência potencial, depuração mais complexa e carga operacional aumentada. 

 **Práticas comuns que devem ser evitadas:** 
+  O [microsserviço *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) é uma situação em que os componentes atômicos se tornam tão altamente interdependentes que a falha de um resulta em uma falha muito maior, o que torna os componentes tão rígidos e frágeis quanto um monólito. 

 **Benefícios de estabelecer esta prática:** 
+  Mais segmentos específicos geram maior agilidade, flexibilidade organizacional e escalabilidade. 
+  Redução do impacto das interrupções do serviço. 
+  Os componentes da aplicação podem ter requisitos de disponibilidade diferentes, aos quais uma segmentação mais atômica pode oferecer suporte. 
+  Responsabilidades bem definidas para as equipes que oferecem suporte à workload. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Escolha o tipo de arquitetura com base no modo como você segmentará a workload. Escolha uma SOA ou arquitetura de microsserviços (ou, em alguns casos, uma arquitetura monolítica). Mesmo que você opte por começar com uma arquitetura monolítica, é necessário garantir que ela seja modular e tenha a capacidade de evoluir para SOA ou microsserviços à medida que o produto escala com a adoção do usuário. A SOA e os microsserviços oferecem, respectivamente, segmentação menor, que é preferida como uma arquitetura moderna escalável e confiável, mas há compensações a serem consideradas, especialmente ao implantar uma arquitetura de microsserviços. 

 Uma compensação primária é que você agora tem uma arquitetura de computação distribuída que pode tornar mais difícil alcançar requisitos de latência do usuário final, e há complexidade adicional na depuração e no rastreamento de interações com o usuário. Use o AWS X-Ray para ajudar você a resolver esse problema. Outro efeito a ser considerado é o aumento da complexidade operacional à medida que você aumenta o número de aplicações que está gerenciando, o que requer a implantação de vários componentes de independência. 

![\[Diagrama de comparação entre arquiteturas monolítica, orientada a serviços e de microsserviços\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/monolith-soa-microservices-comparison.png)


## Etapas de implementação
<a name="implementation-steps"></a>
+  Determine a arquitetura adequada para refatorar ou desenvolver sua aplicação. A SOA e os microsserviços oferecem respectivamente segmentação menor, que é preferida por ser uma arquitetura moderna escalável e confiável. A SOA pode ser o meio-termo ideal para alcançar uma segmentação menor e também evitar algumas das complexidades dos microsserviços. Para obter mais detalhes, consulte [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html). 
+  Se sua workload aceitá-la e sua organização puder sustentá-la, use uma arquitetura de microsserviços para obter a melhor agilidade e confiabilidade. Para obter mais informações, consulte [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html). 
+  Considere seguir o [padrão *Strangler Fig*](https://martinfowler.com/bliki/StranglerFigApplication.html) para refatorar um monólito em componentes menores. Isso envolve a substituição gradual de componentes específicos da aplicação por novos serviços e aplicações. O [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) atua como ponto de partida para a refatoração incremental. Para obter mais detalhes, consulte [Migração simplificada de workloads on-premises herdadas usando um padrão strangler](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/). 
+  A implementação de microsserviços pode exigir um mecanismo de descoberta de serviços para permitir que esses serviços distribuídos se comuniquem entre si. O [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) pode ser usado com arquiteturas orientadas a serviços para fornecer descoberta e acesso confiáveis aos serviços. O [AWS Cloud Map](https://aws.amazon.com/cloud-map/) também pode ser usado para descoberta dinâmica de serviços baseada em DNS. 
+  Se você estiver migrando de um monólito para SOA, o [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) poderá ajudar a preencher a lacuna como um barramento de serviço ao redesenhar aplicações herdadas na nuvem.
+  Para monólitos existentes com um único banco de dados compartilhado, escolha como reorganizar os dados em segmentos menores. Isso pode acontecer por unidade de negócios, padrão de acesso ou estrutura de dados. A esta altura no processo de refatoração, escolha se deseja prosseguir com um banco de dados relacional ou não relacional (NoSQL). Para obter mais detalhes, consulte [Do SQL ao NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html). 

 **Nível de esforço do plano de implementação:** Alto 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL03-BP02 Criar serviços voltados para domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md) 

 **Documentos relacionados:** 
+  [Amazon API Gateway: configurar uma API REST usando a OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [O que é arquitetura orientada a serviços?](https://aws.amazon.com/what-is/service-oriented-architecture/) 
+  [Contexto delimitado (um padrão central no design orientado por domínio)](https://martinfowler.com/bliki/BoundedContext.html) 
+  [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [Microsserviços: uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html) 
+  [Microsserviços na AWS](https://aws.amazon.com/microservices/) 
+  [O que é AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) 

 **Exemplos relacionados:** 
+  [Workshop Modernização iterativa de aplicações](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro) 

 **Vídeos relacionados:** 
+  [Como entregar excelência com microsserviços na AWS](https://www.youtube.com/watch?v=otADkIyugzY) 

# REL03-BP02 Criar serviços voltados para domínios e funcionalidades de negócios específicos
<a name="rel_service_architecture_business_domains"></a>

A arquitetura orientada a serviços (SOA) define serviços com funções bem delineadas estabelecidas pelas necessidades dos negócios. Os microsserviços usam modelos de domínio e contexto delimitado para traçar limites de serviço ao longo dos limites do contexto de negócios. O foco nos domínios de negócios e na funcionalidade ajuda as equipes a definir requisitos independentes de confiabilidade para seus serviços. Contextos delimitados isolam e encapsulam a lógica de negócios, permitindo que as equipes raciocinem melhor sobre como lidar com falhas.

 **Resultado desejado:** em conjunto, engenheiros e partes interessadas do negócio definem contextos delimitados e os usam para projetar sistemas como serviços que cumprem funções empresariais específicas. Essas equipes usam práticas estabelecidas, como Event Storming, para definir os requisitos. As novas aplicações são projetadas como serviços, limites bem definidos e acoplamento fraco. Os monólitos existentes são decompostos em [contextos limitados](https://martinfowler.com/bliki/BoundedContext.html), e os projetos de sistemas migram para arquiteturas SOA ou de microsserviços. Quando os monólitos são refatorados, abordagens estabelecidas, como contextos de bolha e padrões de decomposição de monólitos, são aplicadas. 

 Os serviços orientados por domínios são executados como um ou mais processos que não compartilham o estado. Eles respondem de forma independente às flutuações na demanda e lidam com cenários de falha à luz dos requisitos específicos do domínio. 

 **Práticas comuns que devem ser evitadas:** 
+  As equipes são formadas em torno de domínios técnicos específicos, como UI e UX, middleware ou banco de dados, em vez de domínios empresariais específicos. 
+  As aplicações abrangem as responsabilidades do domínio. Serviços que abrangem contextos delimitados podem ser mais difíceis de manter, exigir maiores esforços de teste e que várias equipes de domínio participem das atualizações de software. 
+  As dependências de domínio, como as bibliotecas de entidades de domínio, são compartilhadas entre serviços de uma forma que as alterações em um domínio de serviço exijam alterações em outros domínios de serviço. 
+  Os contratos de serviço e a lógica de negócios não expressam entidades em uma linguagem de domínio comum e consistente, ocasionando camadas de tradução que complicam os sistemas e aumentam os esforços de depuração. 

 **Benefícios de implementar esta prática recomendada:** as aplicações são projetadas como serviços independentes delimitados por domínios de negócios e usam uma linguagem comercial comum. Os serviços podem ser testados e implantados de forma independente. Os serviços atendem aos requisitos de resiliência específicos do domínio implementado. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 O design orientado por domínio (DDD) é a abordagem fundamental para projetar e criar software em torno de domínios empresariais. É útil trabalhar com um framework existente ao criar serviços voltados para domínios empresariais. Ao trabalhar com aplicações monolíticas existentes, você pode utilizar os padrões de decomposição que fornecem técnicas estabelecidas para modernizar aplicações em serviços. 

![\[Fluxograma descrevendo a abordagem do design orientado por domínio.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/domain-driven-decision.png)


 

## Etapas de implementação
<a name="implementation-steps"></a>
+  As equipes podem realizar workshops de [Event Storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) a fim de identificar rapidamente eventos, comandos, agregados e domínios em um formato leve de notas adesivas. 
+  Depois que as entidades e funções de domínio forem formadas em um contexto de domínio, você poderá dividir seu domínio em serviços usando [contexto limitado](https://martinfowler.com/bliki/BoundedContext.html) em que entidades que compartilham características e atributos semelhantes são agrupadas. Com o modelo dividido em contextos, surge um modelo de como delimitar microsserviços. 
  +  Por exemplo, as entidades do site Amazon.com podem incluir pacote, entrega, cronograma, preço, desconto e moeda. 
  +  Pacote, entrega e cronograma são agrupados no contexto de envio, enquanto preço, desconto e moeda são agrupados no contexto de preços. 
+  [A decomposição de monólitos em microsserviços](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) descreve padrões para refatorar microsserviços. O uso de padrões para decomposição por capacidade comercial, subdomínio ou transação se alinha bem às abordagens orientadas por domínio. 
+  Técnicas táticas como o [contexto de bolha](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) permitem introduzir o DDD em aplicações existentes ou legadas sem reformulações antecipadas e compromissos totais com o DDD. Em uma abordagem de contexto de bolha, um pequeno contexto limitado é estabelecido usando um mapeamento e coordenação de serviços, ou [camada corrompimento](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), que protege o modelo de domínio recém-definido contra influências externas. 

 Depois que as equipes realizarem a análise de domínio e definirem entidades e contratos de serviço, elas podem utilizar os serviços da AWS para implementar o design orientado por domínio como serviços baseados em nuvem. 
+  Comece o desenvolvimento definindo testes que simulem as regras de negócios do seu domínio. O desenvolvimento orientado por testes (TDD) e o desenvolvimento orientado por comportamento (BDD) ajudam as equipes a manter os serviços voltados para a solução de problemas de negócios. 
+  Selecione os [serviços da AWS](https://aws.amazon.com/microservices/) que melhor atendem aos requisitos de domínio da sua empresa e à [arquitetura de microsserviços](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html): 
  +  A [tecnologia sem servidor da AWS](https://aws.amazon.com/serverless/) permite que sua equipe enfoque a lógica de domínio específica em vez de gerenciar servidores e infraestrutura. 
  +  Os [contêineres na AWS](https://aws.amazon.com/containers/) simplificam o gerenciamento de sua infraestrutura para que você possa enfocar nos requisitos de domínio. 
  +  Os [bancos de dados com propósito específico](https://aws.amazon.com/products/databases/) ajudam você a adequar seus requisitos de domínio ao tipo de banco de dados mais adequado. 
+  [Criar arquiteturas hexagonais na AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) descreve uma framework para criar lógica de negócios em serviços que funcionam retroativamente a partir de um domínio empresarial para atender aos requisitos funcionais e, depois, conectar adaptadores de integração. Os padrões que separam os detalhes da interface da lógica de negócios com serviços da AWS ajudam as equipes a enfocar na funcionalidade do domínio e melhorar a qualidade do software. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP03 Fornecer contratos de serviço por API](rel_service_architecture_api_contracts.md) 

 **Documentos relacionados:** 
+ [Microsserviços da AWS](https://aws.amazon.com/microservices/)
+  [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [Como dividir um monólito em microsserviços](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [Conceitos básicos do DDD quando cercado por sistemas herdados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+ [Design orientado por domínio: como lidar com a complexidade no núcleo do software](https://www.amazon.com/gp/product/0321125215)
+ [Criação de arquiteturas hexagonais na AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [Decompor monólitos em microsserviços](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [Event Storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [Mensagens entre contextos delimitados](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [Microsserviços](https://www.martinfowler.com/articles/microservices.html)
+ [Desenvolvimento orientado por testes](https://en.wikipedia.org/wiki/Test-driven_development)
+ [Desenvolvimento orientado por comportamento](https://en.wikipedia.org/wiki/Behavior-driven_development)

 **Exemplos relacionados:** 
+ [Como projetar microsserviços nativos da nuvem na AWS (do DDD/EventStormingWorkshop)](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)

 **Ferramentas relacionadas:** 
+ [Bancos de dados na Nuvem AWS](https://aws.amazon.com/products/databases/)
+ [Tecnologia sem servidor na AWS](https://aws.amazon.com/serverless/)
+ [Contêineres na AWS](https://aws.amazon.com/containers/)

# REL03-BP03 Fornecer contratos de serviço por API
<a name="rel_service_architecture_api_contracts"></a>

Os contratos de serviço são acordos documentados entre produtores e consumidores de API estabelecidos em uma definição de API legível por máquina. Uma estratégia de versionamento de contrato permite que os consumidores continuem usando a API existente e migrem suas aplicações para uma API mais recente quando estiverem prontos. A implantação do produtor pode acontecer a qualquer momento, desde que o contrato seja cumprido. A equipe de serviços pode usar a pilha de tecnologia de sua preferência para cumprir o contrato de API. 

 **Resultado desejado:** as aplicações criadas com arquiteturas orientadas a serviços ou de microsserviços podem operar de forma independente e, ao mesmo tempo, ter uma dependência de tempo de execução integrada. As alterações implantadas em um consumidor ou produtor de API não interrompem a estabilidade do sistema geral quando os dois lados seguem um contrato de API comum. Os componentes que se comunicam por meio de APIs de serviço podem realizar lançamentos funcionais independentes, atualizações para dependências de runtime ou fazer failover em um site de recuperação de desastres (DR) com pouco ou nenhum impacto entre si. Além disso, serviços diferentes são capazes de escalar de forma independente a absorção da demanda de recursos sem exigir que outros serviços escalem simultaneamente. 

 **Práticas comuns que devem ser evitadas:** 
+  Criação de APIs de serviço sem esquemas altamente tipificados. Isso resulta em APIs que não podem ser usadas para gerar vinculações de API e payloads que não podem ser validadas de maneira programática. 
+  Não adotar uma estratégia de versionamento, o que força os consumidores de API a atualizarem e lançarem ou falharem com a evolução dos contratos de serviço. 
+  Mensagens de erro que vazam detalhes da implementação do serviço subjacente em vez de descreverem falhas de integração no contexto e no idioma do domínio. 
+  Não usar contratos de API para desenvolver casos de teste e simular implementações de API para permitir testes independentes dos componentes do serviço. 

 **Benefícios de implementar esta prática recomendada:** sistemas distribuídos compostos por componentes que se comunicam por meio de contratos de serviço de API podem aumentar a confiabilidade. Os desenvolvedores podem detectar possíveis problemas no início do processo de desenvolvimento com a verificação de tipo durante a compilação a fim de verificar se as solicitações e as respostas seguem o contrato da API e se os campos obrigatórios estão presentes. Os contratos de API oferecem uma interface clara de autodocumentação de APIs e oferecem melhor interoperabilidade entre diferentes sistemas e linguagens de programação. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Depois de identificar os domínios de negócios e determinar a segmentação da workload, você pode desenvolver suas APIs de serviço. Primeiro, defina contratos de serviço legíveis por máquina para APIs e, depois, implemente uma estratégia de versionamento de API. Quando estiver pronto para integrar serviços em protocolos comuns, como REST, GraphQL ou eventos assíncronos, você poderá incorporar serviços da AWS à sua arquitetura para integrar seus componentes com contratos de API altamente tipificados. 

 **Serviços da AWS para contratos de API de serviços** 

 Incorpore serviços da AWS, incluindo o [Amazon API Gateway](https://aws.amazon.com/api-gateway/), o [AWS AppSync](https://aws.amazon.com/appsync/) e o [Amazon EventBridge](https://aws.amazon.com/eventbridge/), em sua arquitetura para usar contratos de serviços de API em sua aplicação. O Amazon API Gateway ajuda você a se integrar diretamente com serviços da AWS nativos e outros serviços Web. O API Gateway é compatível com a [especificação da OpenAPI](https://github.com/OAI/OpenAPI-Specification) e versionamento. O AWS AppSync é um endpoint gerenciado do [GraphQL](https://graphql.org/) que você configura definindo um esquema do GraphQL para definir uma interface de serviço para consultas, mutações e assinaturas. O Amazon EventBridge usa esquemas de eventos para definir eventos e gerar vinculações de código para seus eventos. 

## Etapas de implementação
<a name="implementation-steps"></a>
+  Primeiro, defina um contrato para sua API. Um contrato expressará os recursos de uma API, bem como definirá objetos e campos de dados altamente tipificados para a entrada e a saída da API. 
+  Ao configurar APIs no API Gateway, você pode importar e exportar especificações da OpenAPI para seus endpoints. 
  +  [Importar uma definição da OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) simplifica a criação de sua API e pode ser integrada a ferramentas de infraestrutura como código da AWS, como o [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) e o [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/). 
  +  [Exportar uma definição de API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) simplifica a integração a ferramentas de teste de API e oferece ao consumidor de serviços uma especificação de integração. 
+  Você pode definir e gerenciar as APIs do GraphQL com o AWS AppSync [definindo um arquivo de esquema do GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) para gerar sua interface de contrato e simplificar a interação com modelos REST complexos, várias tabelas de banco de dados ou serviços legados. 
+  Os projetos do [AWS Amplify](https://aws.amazon.com/amplify/) integrados ao AWS AppSync geram arquivos de consulta JavaScript altamente tipificados para uso em sua aplicação, bem como uma biblioteca cliente do AWS AppSync GraphQL para tabelas do [Amazon DynamoDB](https://aws.amazon.com/dynamodb/). 
+  Quando você consome eventos de serviço do Amazon EventBridge, eles seguem os esquemas já existentes no registro do esquema ou os definidos com a especificação da OpenAPI. Com um esquema definido no registro, também é possível gerar vinculações de cliente a partir do contrato de esquema para integrar seu código aos eventos. 
+  Estender ou realizar o versionamento de sua API. Estender uma API é uma opção mais simples ao adicionar campos que podem ser configurados com campos opcionais ou valores padrão para campos obrigatórios. 
  +  Contratos baseados em JSON para protocolos, como REST e GraphQL, podem ser uma boa opção para a extensão do contrato. 
  +  Contratos baseados em XML para protocolos, como SOAP, devem ser testados com consumidores de serviços para determinar a viabilidade da extensão do contrato. 
+  Ao realizar o versionamento de uma API, considere implementar o controle de versão por procuração em que uma fachada é usada para oferecer compatibilidade com versões para que a lógica possa ser mantida em uma única base de código. 
  +  Com o API Gateway, você pode usar [mapeamentos de solicitação e resposta](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) para simplificar a absorção de alterações no contrato estabelecendo uma fachada para fornecer valores padrão para novos campos ou para retirar os campos removidos de uma solicitação ou resposta. Com essa abordagem, o serviço subjacente pode manter uma única base de código. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP02 Criar serviços voltados para domínios e funcionalidades de negócios específicos](rel_service_architecture_business_domains.md) 
+  [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md) 
+  [REL05-BP03 Controlar e limitar chamadas de novas tentativas](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md) 

 **Documentos relacionados:** 
+ [O que é uma API (interface de programação de aplicações)?](https://aws.amazon.com/what-is/api/)
+ [Implementar microsserviços na AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [Compensações de microsserviços](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microsserviços: uma definição desse novo termo de arquitetura](https://www.martinfowler.com/articles/microservices.html)
+ [Microsserviços na AWS](https://aws.amazon.com/microservices/)
+ [Trabalhar com extensões do API Gateway para OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [Especificação da OpenAPI](https://github.com/OAI/OpenAPI-Specification)
+ [GraphQL: esquemas e tipos](https://graphql.org/learn/schema/)
+ [Vinculações de código do Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)

 **Exemplos relacionados:** 
+ [Amazon API Gateway: configurar uma API REST usando a OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Amazon API Gateway para a aplicação CRUD do Amazon DynamoDB usando a OpenAPI](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [Padrões modernos de integração de aplicações em uma era sem servidor: integração do serviço do API Gateway](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [Implementar o versionamento do API Gateway baseado em cabeçalho com o Amazon CloudFront](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: como criar uma aplicação cliente](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)

 **Vídeos relacionados:** 
+ [Usar OpenAPI na AWS SAM para gerenciar o API Gateway](https://www.youtube.com/watch?v=fet3bh0QA80)

 **Ferramentas relacionadas:** 
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)

# Projete as interações em um sistema distribuído para evitar falhas
<a name="design-interactions-in-a-distributed-system-to-prevent-failures"></a>

 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
<a name="rel_prevent_interaction_failure_identify"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="resources"></a>

 **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
<a name="rel_prevent_interaction_failure_loosely_coupled_system"></a>

 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/reliability-pillar/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
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_prevent_interaction_failure_constant_work"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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
<a name="rel_prevent_interaction_failure_idempotent"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>

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
<a name="resources"></a>

 **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/) 
+  [AWS LambdaPágina do Powertools no GitHub](https://github.com/aws-powertools/) 

# Projete as interações em um sistema distribuído para mitigar ou resistir a falhas
<a name="design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures"></a>

 Os sistemas distribuídos dependem de redes de comunicação para interconectar componentes (como servidores ou serviços). Sua 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 permitem que as workloads resistam a estresses ou falhas, recuperem-se mais rapidamente e reduzam o impacto de possíveis prejuízos. Como resultado, o tempo médio para recuperação (MTTR) é melhorado. 

 Essas práticas recomendadas evitam falhas e melhoram o tempo médio entre falhas (MTBF). 

**Topics**
+ [REL05-BP01 Implementar uma degradação normal para transformar dependências rígidas aplicáveis em dependências flexíveis](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Controlar a utilização de solicitações](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controlar e limitar chamadas de novas tentativas](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Antecipar-se à falha e limitar filas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Criar serviços sem estado sempre que possível](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementar medidas emergenciais](rel_mitigate_interaction_failure_emergency_levers.md)

# REL05-BP01 Implementar uma degradação normal para transformar dependências rígidas aplicáveis em dependências flexíveis
<a name="rel_mitigate_interaction_failure_graceful_degradation"></a>

Os componentes da aplicação devem continuar desempenhando sua função principal mesmo que as dependências se tornem indisponíveis. Eles podem estar fornecendo dados um pouco obsoletos, dados alternativos ou até mesmo nenhum dado. Isso garante que o funcionamento geral do sistema seja minimamente impedido por falhas localizadas e, ao mesmo tempo, ofereça o valor empresarial central.

 **Resultado desejado:** quando as dependências de um componente não estão íntegras, o próprio componente ainda pode funcionar, embora de maneira prejudicada. Os modos de falha dos componentes devem ser vistos como operação normal. Os fluxos de trabalho devem ser projetados de forma que essas falhas não ocasionem à falha total ou, pelo menos, a estados previsíveis e recuperáveis. 

 **Práticas comuns que devem ser evitadas:** 
+  Não identificar a principal funcionalidade empresarial necessária. Não testar se os componentes estão funcionando mesmo durante falhas de dependência. 
+  Não fornecer dados sobre erros ou quando apenas uma das várias dependências não está disponível e resultados parciais ainda podem ser retornados. 
+  Criar um estado inconsistente quando uma transação falha parcialmente. 
+  Não ter uma forma alternativa de acessar um armazenamento de parâmetros central. 
+  Invalidar ou esvaziar o estado local como resultado de uma falha na atualização sem levar em conta as consequências de fazer isso. 

 **Benefícios de implementar esta prática recomendada:** a degradação gradual melhora a disponibilidade do sistema como um todo e mantém as funções mais importantes em execução mesmo durante falhas. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 A implementação de uma degradação gradual ajuda a minimizar o impacto das falhas de dependência na função do componente. Preferencialmente, um componente detecta falhas de dependência e as contorna de uma maneira que afeta minimamente outros componentes ou clientes. 

 Arquitetar para uma degradação gradual significa considerar possíveis modos de falha durante o projeto de dependência. Para cada modo de falha, tenha uma maneira de fornecer a maior parte ou pelo menos a funcionalidade mais crítica do componente para chamadores ou clientes. Essas considerações podem se tornar requisitos adicionais que podem ser testados e verificados. Preferencialmente, um componente é capaz de realizar sua função principal de maneira aceitável, mesmo quando uma ou várias dependências falham. 

 Trata-se tanto de uma discussão empresarial quanto técnica. Todos os requisitos comerciais são importantes e devem ser atendidos, se possível. No entanto, ainda faz sentido perguntar o que deve acontecer quando nem todos eles podem ser cumpridos. Um sistema pode ser projetado para estar disponível e ser consistente, mas em circunstâncias em que um requisito deve ser descartado, qual deles é mais importante? Para o processamento de pagamentos, pode ser a consistência. Para uma aplicação em tempo real, pode ser a disponibilidade. Para um site voltado para o cliente, a resposta pode depender das expectativas do cliente. 

 O que isso significa depende dos requisitos do componente e do que deve ser considerado sua função principal. Por exemplo: 
+  Um site de comércio eletrônico pode exibir dados de vários sistemas diferentes, como recomendações personalizadas, produtos mais bem classificados e status dos pedidos dos clientes na página de pouso. Quando um sistema upstream falha, ainda faz sentido exibir todo o resto em vez de mostrar uma página de erro para um cliente. 
+  Um componente que executa gravações em lote ainda poderá continuar processando um lote se ocorrer uma falha em uma das operações individuais. Deve ser simples implementar um mecanismo de novas tentativas. Isso pode ser feito retornando informações sobre quais operações foram bem-sucedidas, quais falharam e por que falharam para o chamador, ou colocando solicitações com falha em uma fila de mensagens não entregues para implementar novas tentativas assíncronas. As informações sobre operações com falha também devem ser registradas em log. 
+  Um sistema que processa transações deve verificar se todas ou nenhuma atualização individual foi executada. Para transações distribuídas, o padrão saga pode ser usado para reverter operações anteriores caso ocorra uma falha em uma operação posterior da mesma transação. Aqui, a função principal é manter a consistência. 
+  Sistemas essenciais devem ser capazes de lidar com dependências não correspondentes em tempo hábil. Nesses casos, o padrão de disjuntor pode ser usado. Quando as respostas de uma dependência começam a atingir o tempo limite, o sistema pode mudar para um estado fechado em que nenhuma chamada adicional é realizada. 
+  Uma aplicação pode ler parâmetros de um armazenamento de parâmetros. Pode ser útil criar imagens de contêiner com um conjunto padrão de parâmetros e usá-las caso o armazenamento de parâmetros não esteja disponível. 

 Observe que as vias percorridas em caso de falha do componente precisam ser testadas e devem ser significativamente mais simples do que a via principal. Em geral, [estratégias de fallback devem ser evitadas](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/). 

## Etapas de implementação
<a name="implementation-steps"></a>

 Identifique dependências externas e internas. Leve em conta quais tipos de falhas podem ocorrer nelas. Pense em maneiras de minimizar o impacto negativo nos sistemas upstream e downstream e nos clientes durante essas falhas. 

 Veja a seguir uma lista de dependências e como degradar normalmente quando elas falham: 

1.  **Falha parcial das dependências:** um componente pode fazer várias solicitações para sistemas downstream, como várias solicitações para um sistema ou uma solicitação para vários sistemas cada. Dependendo do contexto empresarial, diferentes maneiras de lidar com isso podem ser apropriadas (para obter mais detalhes, consulte exemplos anteriores em Orientações de implementação). 

1.  **Um sistema downstream não consegue processar solicitações devido à alta carga:** se as solicitações para um sistema downstream falharem constantemente, não fará sentido continuar tentando novamente. Isso pode criar carga adicional em um sistema já sobrecarregado e dificultar a recuperação. O padrão de disjuntor pode ser utilizado aqui, o qual monitora as chamadas com falha para um sistema downstream. Se ocorrer uma falha em um grande número de chamadas, ele deixará de enviar mais solicitações para o sistema downstream e só ocasionalmente permitirá que as chamadas passem para testar se o sistema downstream está disponível novamente. 

1.  **Uma loja de parâmetros não está disponível:** para transformar um armazenamento de parâmetros, é possível usar o armazenamento em cache flexível de dependências ou padrões razoáveis incluídos nas imagens do contêiner ou da máquina. Observe que esses padrões precisam ser mantidos atualizados e incluídos nos pacotes de testes. 

1.  **Um serviço de monitoramento ou outra dependência não funcional não está disponível:** se um componente não conseguir enviar logs, métricas ou rastreamentos de forma intermitente para um serviço de monitoramento central, geralmente é melhor continuar executando as funções empresariais normalmente. Não registrar em log nem enviar métricas silenciosamente por um longo período geralmente não é aceitável. Além disso, alguns casos de uso podem exigir entradas de auditoria completas para atender aos requisitos de conformidade. 

1.  **Uma instância primária de um banco de dados relacional pode estar indisponível:** o Amazon Relational Database Service, como quase todos os bancos de dados relacionais, só pode ter uma instância de gravador principal. Isso cria um único ponto de falha para workloads de gravação e dificulta o ajuste de escala. Isso pode ser parcialmente reduzido com o uso de uma configuração Multi-AZ para alta disponibilidade ou do Amazon Aurora Sem Servidor para melhor ajuste de escala. Para requisitos de disponibilidade muito altos, pode fazer sentido não confiar no gravador principal. Para consultas que são somente leitura, é possível usar réplicas de leitura que fornecem redundância e a capacidade de aumentar a escala horizontalmente, e não apenas verticalmente. As gravações podem ser armazenadas em buffer, por exemplo, em uma fila do Amazon Simple Queue Service, para que as solicitações de gravação dos clientes ainda possam ser aceitas mesmo que a principal esteja temporariamente indisponível. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon API Gateway: controlar as solicitações de API para um melhor throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+  [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html) (resume "Disjuntor" do livro "Release It\$1") 
+  [Novas tentativas em caso de erro e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [Michael Nygard "Release It\$1 Design and Deploy Production-Ready Software](https://pragprog.com/titles/mnee2/release-it-second-edition/)" 
+  [Amazon Builders' Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [Amazon Builders' Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [Amazon Builders' Library: desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 
+  [Amazon Builders' Library: tempos limite, novas tentativas e recuo com jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 

 **Vídeos relacionados:** 
+  [Novas tentativas, recuo e jitter: AWS re:Invent 2019: Introdução à Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

# REL05-BP02 Controlar a utilização de solicitações
<a name="rel_mitigate_interaction_failure_throttle_requests"></a>

Controle a utilização das solicitações para reduzir o esgotamento de recursos devido a aumentos inesperados na demanda. Solicitações abaixo das taxas de controle de utilização são processadas, enquanto aquelas acima do limite definido são rejeitadas com uma mensagem de retorno indicando que o uso da solicitação foi controlado. 

 **Resultado desejado:** grandes picos de volume, sejam causados por aumentos repentinos de tráfego de clientes, ataques de inundação ou tempestades de novas tentativas, são reduzidos pelo controle de utilização de solicitações, permitindo que as workloads continuem com o processamento normal do volume de solicitações compatível. 

 **Práticas comuns que devem ser evitadas:** 
+  Os controles de utilização de endpoint da API não são implementados ou são mantidos em valores padrão sem considerar os volumes esperados. 
+  Não há teste de carregamento nem limites de controle de utilização para os endpoints da API. 
+  Controlar a utilização de taxas de solicitações sem considerar o tamanho ou a complexidade da solicitação. 
+  Testar as taxas máximas de solicitação ou o tamanho máximo da solicitação, mas não testar os dois juntos. 
+  Os recursos não são provisionados nos mesmos limites estabelecidos nos testes. 
+  Os planos de uso não foram configurados nem considerados para consumidores de API de aplicação para aplicação (A2A). 
+  Os consumidores da fila que escalam horizontalmente não têm as configurações máximas de simultaneidade configuradas. 
+  A limitação de taxas por endereço IP não foi implementada. 

 **Benefícios de implementar esta prática recomendada:** as workloads que definem limites de controle de utilização podem operar normalmente e processar a carga de solicitações aceitas com êxito em picos de volume inesperados. Os picos repentinos ou contínuos de solicitações para APIs e filas têm controle de utilização e não esgotam os recursos de processamento de solicitações. Os limites de taxas controlam a utilização de solicitantes individuais para que grandes volumes de tráfego de um único endereço IP ou consumidor de API não esgotem os recursos e afetem outros consumidores. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Os serviços devem ser projetados para processar uma capacidade conhecida de solicitações; essa capacidade pode ser estabelecida por meio de testes de carga. Se as taxas de chegada de solicitações excederem os limites, a resposta apropriada sinalizará que uma solicitação teve controle de utilização. Isso permite que o consumidor resolva o erro e tente novamente mais tarde. 

 Quando seu serviço exigir uma implementação de controle de utilização, considere implementar o algoritmo de bucket de token, em que um token é contabilizado para uma solicitação. Os tokens são recarregados a uma taxa de controle de utilização por segundo e esvaziados de forma assíncrona por meio de um token por solicitação. 

![\[Diagrama que descreve o algoritmo do bucket de token.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/latest/reliability-pillar/images/token-bucket-algorithm.png)


 

 O [Amazon API Gateway](https://aws.amazon.com/api-gateway/) implementa o algoritmo do bucket de token de acordo com os limites da conta e da região e pode ser configurado por cliente com planos de uso. Além disso, o [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) e o [Amazon Kinesis](https://aws.amazon.com/kinesis/) podem armazenar solicitações em buffer para suavizar a taxa de solicitações e permitir taxas de limitação mais altas para solicitações que podem ser atendidas. Por fim, é possível implementar a limitação de taxa com o [AWS WAF](https://aws.amazon.com/waf/) para limitar consumidores de API específicos que geram uma carga excepcionalmente alta. 

## Etapas de implementação
<a name="implementation-steps"></a>

 É possível configurar o API Gateway com limites de limitação para suas APIs e retornar erros `429 Too Many Requests` quando os limites são excedidos. É possível usar o AWS WAF com seus endpoints do AWS AppSync e do APÌ Gateway para habilitar o limite de taxa por endereço IP. Além disso, se seu sistema tolerar o processamento assíncrono, será possível colocar mensagens em uma fila ou em um fluxo para acelerar as respostas aos clientes do serviço, o que permite que você atinja taxas de controle de utilização mais altas. 

 Com o processamento assíncrono, ao configurar o Amazon SQS como fonte de eventos para o AWS Lambda, você pode [configurar a simultaneidade máxima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) para evitar que altas taxas de eventos consumam a cota de execução simultânea disponível da conta necessária para outros serviços em sua workload ou conta. 

 Embora o API Gateway ofereça uma implementação gerenciada do bucket de token, em casos em que não é possível usar o API Gateway, é possível utilizar as implementações de código aberto específicas da linguagem (veja exemplos relacionados em Recursos) do bucket de token para seus serviços. 
+  Entenda e configure os [limites de controle de utilização do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) no nível da conta por região, API por estágio e chave de API por nível do plano de uso. 
+  Aplique [regras de limitação de taxa do AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) ao API Gateway e aos endpoints do AWS AppSync para se proteger contra inundações e bloquear IPs maliciosos. As regras de controle de utilização de taxas também podem ser configuradas em chaves de API do AWS AppSync para consumidores A2A. 
+  Decida se você precisa de mais controle de limitação do que limitação de taxas para APIs do AWS AppSync e, em caso afirmativo, configure um API Gateway na frente do seu endpoint do AWS AppSync. 
+  Quando as filas do Amazon SQS são configuradas como acionadores para consumidores de filas do Lambda, [defina a simultaneidade máxima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) para um valor que processe o suficiente para atender aos seus objetivos de nível de serviço, mas não consuma limites de simultaneidade que afetem outras funções do Lambda. Considere definir a simultaneidade reservada em outras funções do Lambda na mesma conta e região ao consumir filas com o Lambda. 
+  Use o API Gateway com integrações de serviços nativos ao Amazon SQS ou Kinesis para armazenar solicitações em buffer. 
+  Se você não puder usar o API Gateway, consulte bibliotecas específicas de linguagens para implementar o algoritmo do bucket de token para sua workload. Confira a seção de exemplos e faça sua própria pesquisa para encontrar uma biblioteca adequada. 
+  Teste os limites que você planeja definir ou permitir que sejam aumentados e documente os limites testados. 
+  Não aumente os limites além do que foi estabelecido nos testes. Ao aumentar um limite, verifique se os recursos provisionados já são equivalentes ou maiores do que os dos cenários de teste antes de aplicar o aumento. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL04-BP03 Fazer um trabalho constante](rel_prevent_interaction_failure_constant_work.md) 
+  [REL05-BP03 Controlar e limitar chamadas de novas tentativas](rel_mitigate_interaction_failure_limit_retries.md) 

 **Documentos relacionados:** 
+  [Amazon API Gateway: controlar as solicitações de API para um melhor throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) 
+ [AWS WAF: declaração de regra baseada em intervalos](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [Introduzir simultaneidade máxima do AWS Lambda ao usar o Amazon SQS como fonte de eventos](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: simultaneidade máxima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)

 **Exemplos relacionados:** 
+ [As três regras mais importantes baseadas em taxas do AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [Java Bucket4j](https://github.com/bucket4j/bucket4j)
+ [Bucket de tokens do Python](https://pypi.org/project/token-bucket/)
+ [Bucket de tokens do Node](https://www.npmjs.com/package/tokenbucket)
+ [Limitação da taxa de segmentação do .NET System](https://www.nuget.org/packages/System.Threading.RateLimiting)

 **Vídeos relacionados:** 
+ [Implementar as práticas recomendadas de segurança da API GraphQL com o AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)

 **Ferramentas relacionadas:** 
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [Amazon SQS](https://aws.amazon.com/sqs/)
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
+ [Sala de Espera Virtual na AWS](https://aws.amazon.com/solutions/implementations/virtual-waiting-room-on-aws/)

# REL05-BP03 Controlar e limitar chamadas de novas tentativas
<a name="rel_mitigate_interaction_failure_limit_retries"></a>

Use o recuo exponencial para tentar as solicitações novamente em intervalos progressivamente maiores entre cada nova tentativa. Introduza jitter entre as novas tentativas para tornar os intervalos de repetição aleatórios. Limite o número máximo de novas tentativas.

 **Resultado desejado:** os componentes típicos em um sistema de software distribuído incluem servidores, balanceadores de carga, bancos de dados e servidores DNS. Durante a operação normal, esses componentes podem responder a solicitações com erros temporários ou limitados, além de erros que seriam persistentes, independentemente de repetições. Quando os clientes fazem solicitações aos serviços, elas consomem recursos, incluindo memória, threads, conexões, portas ou quaisquer outros recursos limitados. Controlar e limitar as repetições é uma estratégia para liberar e minimizar o consumo de recursos para que os componentes do sistema sob pressão não fiquem sobrecarregados. 

 Quando as solicitações do cliente atingem o tempo limite ou recebem respostas de erro, ele deve determinar se deve ou não tentar novamente. Se tentar novamente, ele o fará com um recuo exponencial com jitter e um valor máximo de nova tentativa. Como resultado, os serviços e os processos de backend recebem alívio da carga e do tempo de recuperação automática, ocasionando uma recuperação mais rápida e atendimento bem-sucedido das solicitações. 

 **Práticas comuns que devem ser evitadas:** 
+  Implementar novas tentativas sem adicionar recuo exponencial, jitter e valores máximos de novas tentativas. O recuo e o jitter ajudam a evitar picos artificiais de tráfego devido a novas tentativas coordenadas involuntariamente em intervalos comuns. 
+  Implementar novas tentativas sem testar seus efeitos ou presumir que as novas tentativas já estejam incorporadas a um SDK sem testar cenários de repetição. 
+  Não entender os códigos de erro publicados das dependências, ocasionando novas tentativas de todos os erros, inclusive aqueles com uma causa clara que indica falta de permissão, erro de configuração ou outra condição que, previsivelmente, não será resolvida sem intervenção manual. 
+  Não abordar práticas de observabilidade, incluindo monitoramento e alertas sobre falhas repetidas de serviço para que os problemas subjacentes sejam divulgados e possam ser resolvidos. 
+  Desenvolver mecanismos de novas tentativas personalizados quando os recursos de novas tentativas integrados ou de terceiros são suficientes. 
+  Tentar novamente em várias camadas da pilha de aplicações de uma forma que agrava as novas tentativas, consumindo ainda mais recursos em uma tempestade de repetições. Entenda como esses erros afetam sua aplicação, as dependências nas quais você confia e implemente novas tentativas em apenas um nível. 
+  Tentar novamente chamadas de serviço que não são idempotentes, causando efeitos colaterais inesperados, como resultados duplicados. 

 **Benefícios de implementar esta prática recomendada:** as novas tentativas ajudam os clientes a obter os resultados desejados quando as solicitações falham, mas também consomem mais tempo do servidor para obter as respostas bem-sucedidas que eles desejam. Quando as falhas são raras ou transitórias, as novas tentativas funcionam bem. Quando as falhas são causadas pela sobrecarga de recursos, as novas tentativas podem piorar as coisas. Adicionar um recuo exponencial com jitter às novas tentativas do cliente permite que os servidores se recuperem quando as falhas são causadas pela sobrecarga de recursos. O jitter evita o alinhamento das solicitações em picos, e o recuo diminui a escalação de carga causado pela adição de repetições à carga normal da solicitação. Por fim, é importante configurar um número máximo de novas tentativas ou o tempo decorrido para evitar a criação de backlogs que produzam falhas metaestáveis. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Controle e limite as chamadas de novas tentativas. Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza jitter para tornar esses intervalos de novas tentativas aleatórios e limite o número máximo de repetições. 

 Alguns AWS SDKs implementam novas tentativas e recuo exponencial por padrão. Use essas implementações integradas da AWS quando aplicável em sua workload. Implemente uma lógica semelhante em sua workload ao chamar serviços que sejam idempotentes e em que repetições melhorem a disponibilidade do cliente. Decida quais são os tempos limite e quando parar de tentar novamente com base no seu caso de uso. Crie e simule cenários de teste para esses casos de uso de novas tentativas. 

## Etapas de implementação
<a name="implementation-steps"></a>
+  Determine a camada ideal em sua pilha de aplicações para implementar novas tentativas para os serviços dos quais sua aplicação depende. 
+  Conheça os SDKs existentes que implementam estratégias comprovadas de novas tentativas com retrocesso exponencial e jitter para a linguagem de sua escolha e dê preferência a esses SDKs em vez de escrever suas próprias implementações de repetição. 
+  Verifique se os [serviços são idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) antes de implementar novas tentativas. Depois que as novas tentativas forem implementadas, elas deverão ser testadas e simuladas regularmente na produção. 
+  Ao chamar as APIs de serviço da AWS, use os [AWS SDKs](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) e a [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html) e entenda as opções de configuração de nova tentativa. Determine se os padrões funcionam para seu caso de uso, teste e ajuste conforme necessário. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL04-BP04 Garantir a idempotência das operações de mutação](rel_prevent_interaction_failure_idempotent.md) 
+  [REL05-BP02 Controlar a utilização de solicitações](rel_mitigate_interaction_failure_throttle_requests.md) 
+  [REL05-BP04 Antecipar-se à falha e limitar filas](rel_mitigate_interaction_failure_fail_fast.md) 
+  [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md) 
+  [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md) 

 **Documentos relacionados:** 
+  [Novas tentativas em caso de erro e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) 
+  [Amazon Builders' Library: tempos limite, novas tentativas e recuo com jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 
+ [Recuo exponencial e jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [Tornar as tentativas seguras com APIs idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

 **Exemplos relacionados:** 
+ [Spring Retry](https://github.com/spring-projects/spring-retry)
+ [Resilience4j Retry](https://resilience4j.readme.io/docs/retry)

 **Vídeos relacionados:** 
+  [Novas tentativas, recuo e jitter: AWS re:Invent 2019: Introdução à Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884) 

 **Ferramentas relacionadas:** 
+ [AWS SDKs e ferramentas: comportamento de novas tentativas](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: Novas tentativas via AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)

# REL05-BP04 Antecipar-se à falha e limitar filas
<a name="rel_mitigate_interaction_failure_fail_fast"></a>

Quando um serviço não consegue responder com êxito a uma solicitação, antecipe-se à falha. Isso permite a liberação dos recursos associados a uma solicitação e possibilita que o serviço se recupere se estiver ficando sem recursos. Antecipar-se à falha é um padrão de design de software bem estabelecido que pode ser utilizado para criar workloads altamente confiáveis na nuvem. As filas também correspondem a um padrão de integração empresarial bem estabelecido que pode facilitar o carregamento e permitir que os clientes liberem recursos quando o processamento assíncrono pode ser tolerado. Quando um serviço consegue responder com êxito em condições normais, mas falha quando a taxa de solicitações é muito alta, use uma fila para armazenar solicitações em buffer. No entanto, não permita a formação de backlogs de filas longas que possam ocasionar o processamento de solicitações antigas das quais um cliente já desistiu.

 **Resultado desejado:** quando os sistemas enfrentam contenção de recursos, tempos limite, exceções ou falhas de causa desconhecida que tornam os objetivos de nível de serviço inatingíveis, as estratégias de antecipação a falhas permitem uma recuperação mais rápida do sistema. Sistemas que precisam absorver picos de tráfego e acomodar o processamento assíncrono podem melhorar a confiabilidade ao permitir que os clientes liberem solicitações rapidamente usando filas para armazenar solicitações em buffer para serviços de backend. Ao armazenar solicitações em filas, estratégias de gerenciamento de filas são implementadas para evitar backlogs intransponíveis. 

 **Práticas comuns que devem ser evitadas:** 
+  Implementar filas de mensagens, mas não configurar filas de mensagens não entregues (DLQ) ou alarmes em volumes DLQ para detectar quando um sistema está em falha. 
+  Não medir a idade das mensagens em uma fila, uma medida de latência para entender quando os consumidores da fila estão ficando para trás ou cometendo erros, ocasionando repetições. 
+  Não limpar mensagens pendentes de uma fila, quando não há utilidade em processar essas mensagens se a necessidade empresarial deixar de existir. 
+  Configurar filas do tipo “first in first out” (FIFO) quando filas do tipo “last in first out” (LIFO) atenderia melhor às necessidades do cliente, por exemplo, quando a ordenação rigorosa não é necessária e o processamento de backlog está atrasando todas as solicitações novas e urgentes, ocasionando violação dos níveis de serviço de todos os clientes. 
+  Expor filas internas aos clientes em vez de expor APIs que gerenciem a entrada de trabalho e coloquem as solicitações em filas internas. 
+  Combinar muitos tipos de solicitações de trabalho em uma única fila, o que pode agravar as condições de backlog ao distribuir a demanda de recursos entre os tipos de solicitação. 
+  Processar solicitações complexas e simples na mesma fila, apesar da necessidade de monitoramento, tempos limite e alocação de recursos diferentes. 
+  Não validar entradas ou usar afirmações para implementar mecanismos de antecipação à falha em software que agreguem exceções a componentes de nível superior que podem lidar com erros sem problemas. 
+  Não remover recursos com defeito do roteamento de solicitações, principalmente quando as falhas estão emitindo êxitos e falhas em decorrência de travamento e reinicialização, falha de dependência intermitente, capacidade reduzida ou perda de pacotes de rede. 

 **Benefícios de implementar esta prática recomendada:** sistemas que se antecipam às falhas são mais fáceis de depurar e corrigir e geralmente expõem problemas de codificação e configuração antes que as versões sejam publicadas em produção. Os sistemas que incorporam estratégias eficazes de filas oferecem maior resiliência e confiabilidade a picos de tráfego e às condições intermitentes de falha do sistema. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 As estratégias de antecipação à falha podem ser codificadas em soluções de software e configuradas em infraestrutura. Além de se anteciparem à falha, as filas são uma técnica arquitetônica simples, mas poderosa, para dissociar os componentes do sistema e facilitar o carregamento. O [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) oferece recursos para monitorar e alertar sobre falhas. Quando se sabe que um sistema está falhando, estratégias de mitigação podem ser invocadas, inclusive evitar recursos afetados. Quando os sistemas implementam filas com o [Amazon SQS](https://aws.amazon.com/sqs/) e outras tecnologias de fila para facilitar o carregamento, eles devem considerar como gerenciar os backlogs de filas, bem como as falhas no consumo de mensagens. 

## Etapas de implementação
<a name="implementation-steps"></a>
+  Implemente afirmações programáticas ou métricas específicas em seu software e use-as para alertar explicitamente sobre problemas do sistema. O Amazon CloudWatch ajuda você a criar métricas e alarmes com base no padrão de log da aplicação e na instrumentação do SDK. 
+  Use métricas e alarmes do CloudWatch para eliminar recursos danificados que estão aumentando a latência no processamento ou falhando repetidamente no processamento das solicitações. 
+  Use o processamento assíncrono criando APIs para aceitar e anexar solicitações às filas internas usando o Amazon SQS e, em seguida, responder ao cliente que produz a mensagem com uma mensagem de êxito para que o cliente possa liberar recursos e prosseguir com outros trabalhos enquanto os consumidores da fila de backend processam as solicitações. 
+  Avalie e monitore a latência do processamento da fila produzindo uma métrica do CloudWatch sempre que retirar uma mensagem de uma fila, comparando o momento presente com o carimbo de data/hora da mensagem. 
+  Quando falhas impedem o processamento bem-sucedido de mensagens ou geram picos de tráfego em volumes que não podem ser processados de acordo com acordos de serviço, deixe de lado o tráfego antigo ou excedente para uma fila de transbordamento. Isso permite o processamento prioritário de trabalhos novos e antigos quando há capacidade disponível. Essa técnica é uma aproximação do processamento LIFO e permite o processamento normal do sistema para todos os novos trabalhos. 
+  Use filas de mensagens não entregues ou de redirecionamento para mover mensagens que não podem ser processadas do backlog para um local que possa ser pesquisado e resolvido posteriormente. 
+  Tente novamente ou, quando possível, elimine as mensagens antigas comparando o momento presente com o carimbo de data/hora da mensagem e descartando as mensagens que não são mais relevantes para o cliente solicitante. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL04-BP02 Implementar dependências com acoplamento fraco](rel_prevent_interaction_failure_loosely_coupled_system.md) 
+  [REL05-BP02 Controlar a utilização de solicitações](rel_mitigate_interaction_failure_throttle_requests.md) 
+  [REL05-BP03 Controlar e limitar chamadas de novas tentativas](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL06-BP02 Definir e calcular métricas (agregação)](rel_monitor_aws_resources_notification_aggregation.md) 
+  [REL06-BP07 Monitorar o rastreamento completo das solicitações por meio de seu sistema](rel_monitor_aws_resources_end_to_end.md) 

 **Documentos relacionados:** 
+ [Evitar backlogs de fila intransponíveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+  [Antecipar-se à falha](https://www.martinfowler.com/ieeeSoftware/failFast.pdf) 
+ [Como posso evitar um aumento no atraso das mensagens na minha fila Amazon SQS?](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [Elastic Load Balancing: mudança de zona](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [Amazon Application Recovery Controller: controle de roteamento para failover de tráfego](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)

 **Exemplos relacionados:** 
+ [Padrões de integração empresarial: canal de mensagens não entregues](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)

 **Vídeos relacionados:** 
+  [AWS re:Invent 2022: Operar aplicações Multi-AZ altamente disponíveis](https://www.youtube.com/watch?v=mwUV5skJJ0s) 

 **Ferramentas relacionadas:** 
+ [Amazon SQS](https://aws.amazon.com/sqs/)
+ [Amazon MQ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)

# REL05-BP05 Definir tempos limite do cliente
<a name="rel_mitigate_interaction_failure_client_timeouts"></a>

Defina tempos limite adequados para conexões e solicitações, verifique-os sistematicamente e não confie nos valores padrão, pois eles não estão cientes das especificações da workload.

 **Resultado desejado:** os tempos limite do cliente devem considerar o custo para o cliente, o servidor e a workload associados à espera por solicitações que levam um tempo anormal para serem concluídas. Como não é possível saber a causa exata de nenhum tempo limite, os clientes devem usar o conhecimento dos serviços para desenvolver expectativas de causas prováveis e prazos apropriados. 

 As conexões do cliente atingem o tempo limite com base nos valores configurados. Depois de encontrar um tempo limite, os clientes tomam a decisão de recuar e tentar novamente ou abrir um [disjuntor](https://martinfowler.com/bliki/CircuitBreaker.html). Esses padrões evitam a emissão de solicitações que podem exacerbar uma condição de erro subjacente. 

 **Práticas comuns que devem ser evitadas:** 
+  Não estar ciente dos tempos limite do sistema ou dos tempos limite padrão. 
+  Não estar ciente do tempo normal de conclusão da solicitação. 
+  Não estar ciente das possíveis causas das solicitações levarem muito tempo para serem concluídas ou dos custos de performance do cliente, do serviço ou da workload associados à espera por essas conclusões. 
+  Não estar ciente da probabilidade de uma rede danificada fazer com que uma solicitação falhe somente quando o tempo limite é atingido e dos custos para a performance do cliente e da workload por não adotar um tempo limite mais curto. 
+  Não testar cenários de tempo limite tanto para conexões quanto para solicitações. 
+  Definir tempos limite muito altos, o que pode resultar em longos tempos de espera e aumentar a utilização de recursos. 
+  Definir tempos limite muito baixos, gerando falhas artificiais. 
+  Ignorar padrões para lidar com erros de tempo limite para chamadas remotas, como disjuntores e novas tentativas. 
+  Não considerar o monitoramento de taxas de erro de chamadas de serviço, objetivos de nível de serviço para latência e valores atípicos de latência. Essas métricas podem fornecer informações sobre tempos limite agressivos ou permissivos. 

 **Benefícios de implementar esta prática recomendada:** os tempos limite de chamadas remotas são configurados e os sistemas são projetados para lidar com os tempos limite normalmente de forma que os recursos sejam conservados quando as chamadas remotas respondem de forma anormalmente lenta e os erros de tempo limite sejam tratados normalmente pelos clientes do serviço. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Alto 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada de dependência de serviço e, geralmente, em qualquer chamada entre processos. Muitas frameworks oferecem recursos de tempo limite integrados, mas tenha cuidado, pois algumas têm valores padrão infinitos ou superiores ao aceitável para seus objetivos de serviço. Um valor muito alto reduz a utilidade do tempo limite porque os recursos continuam a ser consumidos enquanto o cliente aguarda o decorrer do tempo limite. Um valor muito baixo pode gerar maior tráfego no backend e maior latência, porque muitas solicitações são repetidas. Em alguns casos, isso pode levar a interrupções completas porque todas as solicitações estão sendo repetidas. 

 Considere o seguinte ao determinar as estratégias de tempo limite: 
+  As solicitações podem levar mais tempo do que o normal para serem processadas devido ao conteúdo, a deficiências em um serviço de destino ou a uma falha na partição de rede. 
+  Solicitações com conteúdo anormalmente caro podem consumir recursos desnecessários do servidor e do cliente. Nesse caso, reduzir o tempo limite dessas solicitações e não tentar novamente pode preservar os recursos. Os serviços também devem se proteger de conteúdo anormalmente caro com limitações e tempos limite do servidor. 
+  Solicitações que demoram muito devido a uma falha no serviço podem expirar e ser repetidas. Deve-se considerar os custos do serviço para a solicitação e a nova tentativa, mas se a causa for uma deficiência localizada, uma nova tentativa provavelmente não será cara e reduzirá o consumo de recursos do cliente. O tempo limite também pode liberar recursos do servidor, dependendo da natureza da deficiência. 
+  Solicitações que demoram muito para serem concluídas porque a solicitação ou a resposta não foi entregue pela rede podem expirar e ser repetidas. Como a solicitação ou a resposta não foi entregue, a falha teria sido o resultado, independentemente da duração do tempo limite. Nesse caso, o tempo limite não liberará recursos do servidor, mas liberará recursos do cliente e melhorará a performance da workload. 

 Aproveite os padrões de design bem estabelecidos, como novas tentativas e disjuntores, para lidar com os tempos de espera de forma eficiente e oferecer compatibilidade com abordagens de antecipação à falha. [AWS Os SDKs](https://docs.aws.amazon.com/index.html#sdks) e a [AWS CLI](https://aws.amazon.com/cli/) permitem a configuração de tempos limite de conexão e solicitação e novas tentativas com recuo exponencial e jitter. As funções do [AWS Lambda](https://aws.amazon.com/lambda/) são compatíveis com a configuração de tempos limite. E, com o [AWS Step Functions](https://aws.amazon.com/step-functions/), você pode criar disjuntores com pouco código que aproveitam as integrações pré-construídas com os serviços e SDKs da AWS. [AWS App Mesh](https://aws.amazon.com/app-mesh/) O Envoy oferece recursos de tempo limite e disjuntor. 

## Etapas de implementação
<a name="implementation-steps"></a>
+  Configure tempos limite em chamadas de serviço remoto e utilize os recursos de tempo limite de linguagem integrados ou as bibliotecas de tempo limite de código aberto. 
+  Quando sua workload fizer chamadas com um AWS SDK, revise a documentação para saber a configuração de tempo limite específica da linguagem. 
  + [Python](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
  + [PHP](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
  + [.NET](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
  + [Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
  + [Java](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
  + [Go](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
  + [Node.js](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
  + [C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+  Ao usar AWS SDKs ou comandos da AWS CLI em sua workload, configure os valores de tempo limite padrão definindo os [padrões de configuração](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) da AWS para `connectTimeoutInMillis` e `tlsNegotiationTimeoutInMillis`. 
+  Aplique [opções de linha de comando](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` e `cli-read-timeout` para controlar comandos da AWS CLI únicos para serviços da AWS. 
+  Monitore o tempo limite de chamadas de serviço remoto e defina alarmes para erros persistentes para que você possa lidar proativamente com cenários de erro. 
+  Implemente [métricas do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e [detecção de anomalias do CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) em taxas de erro de chamada, objetivos de nível de serviço para latência e valores atípicos de latência para fornecer informações sobre o gerenciamento de tempos limite excessivamente agressivos ou permissivos. 
+  Configure tempos limite nas [funções do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console). 
+  Os clientes do API Gateway devem implementar suas próprias repetições ao lidar com os tempos limite. O API Gateway oferece suporte a um [tempo limite de integração de 50 milissegundos a 29 segundos](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) para integrações downstream e não tenta novamente quando a integração solicita o tempo limite. 
+  Implemente o padrão de [disjuntor](https://martinfowler.com/bliki/CircuitBreaker.html) para evitar fazer chamadas remotas quando o tempo limite está prestes a ser atingido. Abra o circuito para evitar falhas nas chamadas e feche-o quando as chamadas estiverem respondendo normalmente. 
+  Para workloads baseadas em contêineres, revise os recursos do [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) para aproveitar os tempos limite e os disjuntores integrados. 
+  Use o AWS Step Functions para criar disjuntores de pouco uso de código para chamadas de serviço remoto, especialmente ao chamar SDKs nativos da AWS e integrações do Step Functions compatíveis para simplificar sua workload. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL05-BP03 Controlar e limitar chamadas de novas tentativas](rel_mitigate_interaction_failure_limit_retries.md) 
+  [REL05-BP04 Antecipar-se à falha e limitar filas](rel_mitigate_interaction_failure_fail_fast.md) 
+  [REL06-BP07 Monitorar o rastreamento completo das solicitações por meio de seu sistema](rel_monitor_aws_resources_end_to_end.md) 

 **Documentos relacionados:** 
+  [AWS SDK: novas tentativas e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html) 
+  [Amazon Builders' Library: tempos limite, novas tentativas e recuo com jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) 
+ [Cotas do Amazon API Gateway e notas importantes](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [Opções de linha de comando do AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: configurar tempos limite de API](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore usando o objeto de configuração e a referência de configuração](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK para .NET: novas tentativas e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: configurar as opções da função do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)

 **Exemplos relacionados:** 
+ [Usar o padrão do disjuntor com o AWS Step Functions e o Amazon DynamoDB](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [Martin Fowler: CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)

 **Ferramentas relacionadas:** 
+ [AWS SDKs](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [Amazon SQS](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)

# REL05-BP06 Criar serviços sem estado sempre que possível
<a name="rel_mitigate_interaction_failure_stateless"></a>

 Os sistemas não devem exigir estado ou devem descarregar o estado de modo que não haja dependência entre solicitações de clientes diferentes em relação aos dados armazenados localmente no disco ou na memória. Isso permite que os servidores sejam substituídos quando necessário sem prejudicar a disponibilidade. 

 Quando os usuários ou serviços interagem com uma aplicação, eles geralmente executam uma série de interações que formam uma sessão. Uma sessão são dados exclusivos para usuários que persistem entre solicitações enquanto usam a aplicação. Uma aplicação sem estado é uma aplicação que não precisa de conhecimento de interações anteriores e não armazena informações da sessão. 

 Depois de projetados para serem sem estado, você pode usar serviços de computação com tecnologia sem servidor, como o AWS Lambda ou o AWS Fargate. 

 Além da substituição do servidor, outro benefício das aplicações sem estado é que elas podem escalar horizontalmente, pois qualquer um dos recursos de computação disponíveis (como instâncias do EC2 e funções do AWS Lambda) pode atender a qualquer solicitação. 

 **Benefícios de implementar esta prática recomendada:** os sistemas projetados para serem sem estado são mais adaptáveis ao dimensionamento horizontal, possibilitando a adição ou remoção de capacidade com base na flutuação do tráfego e da demanda. Eles também são inerentemente resilientes a falhas e oferecem flexibilidade e agilidade no desenvolvimento de aplicações. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>

 Crie aplicações sem estado. As aplicações sem estado permitem o ajuste de escala horizontal e são tolerantes a falhas de um nó individual. Analise e compreenda os componentes da aplicação que mantêm estado dentro da arquitetura. Isso ajuda você a avaliar o impacto potencial da transição para um design sem estado. Uma arquitetura sem estado dissocia os dados de usuários e descarrega os dados de sessões. Isso oferece a flexibilidade de escalar cada componente de forma independente para atender às diferentes demandas de workload e otimizar a utilização de recursos. 

### Etapas de implementação
<a name="implementation-steps"></a>
+  Identifique e compreenda os componentes com estado na aplicação. 
+  Dissocie os dados, separando e gerenciando os dados de usuários da lógica principal da aplicação. 
  +  O [Amazon Cognito](https://aws.amazon.com/cognito/) pode dissociar os dados do usuário do código da aplicação usando recursos, como [bancos de identidades](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html), [grupos de usuários](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-cognito-user-pools.html) e o [Amazon Cognito Sync](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-sync.html). 
  +  É possível usar o [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) para desacoplar dados do usuário armazenando segredos em um local seguro e centralizado. Isso significa que o código da aplicação não precisa armazenar segredos, o que a torna mais segura. 
  +  Considere usar o [Amazon S3](https://aws.amazon.com/s3/) para armazenar dados grandes e não estruturados, como imagens e documentos. Sua aplicação poderá recuperar esses dados quando necessário, eliminando a necessidade de armazená-los na memória. 
  +  Use o [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) para armazenar informações, como perfis de usuário. Sua aplicação poderá consultar esses dados praticamente em tempo real. 
+  Descarregue os dados de sessões em um banco de dados, cache ou arquivos externos. 
  +  O [Amazon ElastiCache](https://aws.amazon.com/elasticache/), o Amazon DynamoDB, o [Amazon Elastic File System](https://aws.amazon.com/efs/) (Amazon EFS) e o [Amazon MemoryDB](https://aws.amazon.com/memorydb/) são exemplos de serviços da AWS que você pode usar para descarregar dados da sessão. 
+  Crie uma arquitetura sem estado depois de identificar quais dados de estado e de usuários precisam ser mantidos com sua solução de armazenamento preferida. 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL11-BP03 Automatizar a reparação em todas as camadas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_auto_healing_system.html) 

 **Documentos relacionados:** 
+  [Amazon Builders' Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems) 
+  [Amazon Builders' Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs) 
+  [Amazon Builders' Library: desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/) 
+  [Práticas recomendadas para níveis na Web sem estado na AWS](https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/stateless-web-tier.html) 

# REL05-BP07 Implementar medidas emergenciais
<a name="rel_mitigate_interaction_failure_emergency_levers"></a>

 Medidas emergenciais são processos rápidos que podem atenuar o impacto da disponibilidade na workload. 

 As medidas emergenciais funcionam com a desativação, o controle de utilização ou a alteração do comportamento dos componentes ou das dependências com o uso de mecanismos conhecidos e testados. Isso pode aliviar as deficiências da workload decorrentes da exaustão dos recursos provocada por aumentos inesperados na demanda e reduzir o impacto de falhas em componentes não essenciais da workload. 

 **Resultado desejado:** ao implementar medidas de emergência, você pode estabelecer processos em boas condições para manter a disponibilidade de componentes essenciais em sua workload. A workload deve se degradar normalmente e continuar desempenhando suas funções essenciais aos negócios durante a ativação de uma medida emergencial. Para obter detalhes sobre a degradação normal, consulte [REL05-BP01 Implementar uma degradação normal para transformar dependências rígidas aplicáveis em dependências flexíveis](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html). 

 **Práticas comuns que devem ser evitadas:** 
+  A falha de dependências não essenciais afeta a disponibilidade da workload principal. 
+  Não testar ou verificar o comportamento dos componentes essenciais durante a deterioração de componentes não essenciais. 
+  Não há critérios claros e determinísticos definidos para ativação ou desativação de uma medida emergencial. 

 **Benefícios de implementar esta prática recomendada:** a implementação de medidas emergenciais pode melhorar a disponibilidade dos componentes críticos em sua workload, fornecendo aos seus resolvedores processos estabelecidos para responder a picos inesperados na demanda ou falhas de dependências não críticas. 

 **Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio 

## Orientação para implementação
<a name="implementation-guidance"></a>
+  Identifique os componentes essenciais na workload. 
+  Projete e arquitete os componentes essenciais na workload para resistirem à falha de componentes não essenciais. 
+  Conduza testes para validar o comportamento dos componentes essenciais durante a falha de componentes não essenciais. 
+  Defina e monitore métricas ou acionadores relevantes para iniciar procedimentos de medida emergencial. 
+  Defina os procedimentos (manuais ou automatizados) que compõem a medida emergencial. 

### Etapas de implementação
<a name="implementation-steps"></a>
+  Identifique os componentes essenciais aos negócios na workload. 
  +  Cada componente técnico na workload deve ser mapeado para a função de negócios relevante e classificado como essencial ou não essencial. Para exemplos de funcionalidades críticas e não críticas na Amazon, consulte [Qualquer dia pode ser o Prime Day: Como a pesquisa da Amazon.com usa a engenharia do caos para lidar com mais de 84 mil solicitações por segundo](https://community.aws/posts/how-search-uses-chaos-engineering). 
  +  Essa é uma decisão técnica e de negócios e varia de acordo com a organização e a workload. 
+  Projete e arquitete os componentes essenciais na workload para resistirem à falha de componentes não essenciais. 
  +  Durante a análise de dependências, considere todos os possíveis modos de falha e verifique se os mecanismos de medida emergencial fornecem a funcionalidade essencial aos componentes subsequentes. 
+  Conduza testes para validar o comportamento dos componentes essenciais durante a ativação das medidas emergenciais. 
  +  Evite comportamento bimodal. Para obter mais detalhes, 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) 
+  Defina, monitore e emita alertas sobre as métricas relevantes para iniciar o procedimento de medida emergencial. 
  +  A descoberta das métricas certas a serem monitoradas depende da workload. Alguns exemplos de métricas são a latência ou o número de solicitações com falha feitas para uma dependência. 
+  Defina os procedimentos, manuais ou automatizados, que compõem a medida emergencial. 
  +  [Isso pode incluir mecanismos como [redução de carga](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), [controle de utilização de solicitações](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) ou implementação de degradação normal](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html). 

## Recursos
<a name="resources"></a>

 **Práticas recomendadas relacionadas:** 
+  [REL05-BP01 Implementar uma degradação normal para transformar dependências rígidas aplicáveis em dependências flexíveis](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html) 
+  [REL05-BP02 Controlar a utilização de solicitações](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) 
+  [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) 

 **Documentos relacionados:** 
+ [Automatizar implantações seguras e sem intervenção](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+  [Qualquer dia pode ser o Prime Day: como a pesquisa da Amazon.com usa a engenharia do caos para lidar com mais de 84 mil solicitações por segundo](https://community.aws/posts/how-search-uses-chaos-engineering) 

 **Vídeos relacionados:** 
+ [AWS re:Invent 2020: Confiabilidade, consistência e confiança por meio da imutabilidade](https://www.youtube.com/watch?v=jUSYnRztttY)