Um aplicativo móvel global de venda de ingressos exibe um código de barras que os scanners de eventos leem. Após a leitura, os dispositivos de scanner chamam uma API de backend para validar o código de barras em um banco de dados e, em seguida, atualizam uma única tabela do banco de dados para marcar o código de barras como usado. A empresa hospedará o banco de dados em três regiões da AWS e precisa de um nome DNS api.example.com. Qual arquitetura oferece a MENOR latência para validação de código de barras e a operação de atualização?

A opção correta utiliza Tabelas Globais do DynamoDB para o banco de dados, que fornece replicação multirregional ativa-ativa e baixa latência para leituras e gravações. A lógica de backend é implementada com Lambda@Edge, que executa o código o mais próximo possível do usuário final (nos locais de borda do CloudFront), minimizando a latência. O CloudFront atua como um CDN e roteia as solicitações para o local de borda mais próximo, e o Route 53 mapeia o nome DNS para a distribuição do CloudFront. As outras opções são menos ideais: Usar clusters globais do Aurora com Global Accelerator é uma boa solução, mas o DynamoDB Global Tables e Lambda@Edge geralmente oferecem latência ainda menor para este tipo de carga de trabalho de leitura/gravação distribuída globalmente. Usar clusters globais do Aurora com CloudFront e EKS introduz mais latência, pois o CloudFront não otimiza o roteamento para os clusters EKS da mesma forma que o Global Accelerator faria para o tráfego de API, e o EKS é mais pesado que Lambda@Edge. Usar Tabelas Globais do DynamoDB com CloudFront Functions é menos flexível do que Lambda@Edge. CloudFront Functions são mais adequadas para manipulações de requisição/resposta leves, enquanto Lambda@Edge pode executar lógica de backend mais complexa e interagir com outros serviços AWS.