As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Comunicação assíncrona
Por outro lado, na comunicação assíncrona, o cliente emite uma solicitação para um serviço, mas não recebe uma resposta imediata. Nesse caso, ele geralmente recebe apenas uma confirmação de que a solicitação foi aceita.
Os benefícios da comunicação assíncrona incluem:
+ **Suporte de arquitetura orientado por eventos**: adequação natural para padrões de terceirização de eventos e segregação de responsabilidade por consultas de comando (CQRS).
+ **Melhor gerenciamento de recursos**: capacidade dos serviços de processar solicitações com base em suas capacidades.
+ **Melhor isolamento de falhas**: desacoplamento de serviços, o que evita falhas em cascata.
+ **Manipulação de picos de carga**: melhor gerenciamento de picos de tráfego por meio do enfileiramento de mensagens.
As desvantagens incluem a complexidade. Por exemplo:
+ Se o cliente exigir o resultado da operação assíncrona, a implementação de um mecanismo para obter ou receber esse resultado exigirá mais esforços.
+ Pode ser mais difícil solucionar problemas em operações assíncronas, porque a solução de problemas exige análises de logs em vários sistemas.
+ Pode ser mais difícil testar operações assíncronas, pois os testes exigem coordenação entre vários sistemas e serviços.
As abordagens de comunicação assíncrona incluem acionar e esquecer, verificar declarações, retorno de chamada e comunicação bidirecional.
## Acionar e esquecer
No padrão “acionar e esquecer”, um cliente emite uma solicitação ao servidor e recebe de forma síncrona uma confirmação indicando que o servidor recebeu a mensagem e a processará. No entanto, o processamento real ainda não ocorreu, e o cliente não tem visibilidade de quando ou como ele será feito. O diagrama a seguir ilustra esse padrão.
Nesse caso, o serviço **não deve** enviar a confirmação até que o objeto seja mantido de forma duradoura. Essa persistência pode ser implementada como uma operação de gravação no banco de dados ou colocando um item em uma fila.
Considerações adicionais:
+ Implemente idempotência para lidar com mensagens duplicadas. Ou seja, cada mensagem deve ser processada apenas uma vez.
+ Considere [filas de mensagens não entregues](https://aws.amazon.com/what-is/dead-letter-queue/) em caso de falha no processamento.
+ Monitore taxas de sucesso de processamento de mensagens.
## Verificação de declaração
Se um cliente precisar do resultado de uma chamada de serviço, você poderá criar o serviço para emitir uma *verificação de declaração* ao receber uma solicitação. O diagrama a seguir ilustra esse padrão. A verificação da declaração é implementada como um identificador que o serviço retorna em sua confirmação. O cliente pode usar esse identificador posteriormente para verificar o status da solicitação e recuperar o resultado quando a solicitação estiver concluída.
Os clientes devem implementar um mecanismo para pesquisar os resultados. Isso pode ser automatizado (por exemplo, uma verificação pode ser realizada a cada *n* minutos) ou implementado manualmente, em que a verificação é realizada em resposta a outro evento ou ação do usuário. Os serviços que implementam o padrão de verificação de declaração devem ser explícitos sobre o período de validade de um verificação de declaração.
Práticas recomendadas:
+ Implemente um recuo exponencial para sondagem.
+ Defina um tempo de vida útil (TTL) para verificações de declarações.
+ Forneça endpoints de status para acompanhamento do progresso.
## Retorno de chamada
No padrão de retorno de chamada, um cliente emite uma solicitação para um serviço e fornece um local para o serviço entrar em contato quando o processamento estiver concluído. O cliente não espera um resultado, e o processamento continua. O serviço é responsável por entrar em contato com o local quando o processamento estiver concluído e fornecer o resultado. Os tipos comuns de locais para respostas são REST APIs ou filas. O diagrama a seguir ilustra o padrão de retorno de chamada.
Implementação:
+ Implemente mecanismos de repetição para retornos de chamada com falha.
+ Proteja o local de retorno da chamada como faria com outros serviços.
+ Gerencie os tempos limite de retorno de chamada.
## Comunicação bidirecional
Para implementar a comunicação bidirecional, você deve criar uma conexão estável entre um cliente e um serviço, que permita que o cliente e o serviço enviem e processem mensagens. Isso é ilustrado no diagrama a seguir. Embora a comunicação seja assíncrona, o serviço deve ser capaz de sustentar uma conexão aberta para cada cliente.
Considerações de implementação:
+ Ordenação de mensagens
+ Números de sequência
+ Estratégias de partição
+ Ordenação de mensagens
+ Gerenciamento de estados
+ Padrões de fornecimento de eventos
+ Conciliação de estado
+ Modelos de consistência
+ Tratamento de erros
+ [Filas de mensagens não entregues](https://aws.amazon.com/what-is/dead-letter-queue/)
+ Política de novas tentativas
+ [Disjuntores](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/circuit-breaker.html)
+ Estratégias de fallback
+ Monitoramento e observabilidade
+ Correlação IDs
+ Rastrear mensagens
+ Métricas de performance
+ Indicadores de integridade do sistema