Uma empresa de e-commerce executa seu aplicativo na AWS. O aplicativo usa um cluster Amazon Aurora PostgreSQL em modo Multi-AZ para o banco de dados. Durante uma recente campanha promocional, o aplicativo experimentou uma alta carga de leitura e gravação. Os usuários tiveram problemas de tempo limite ao acessar o aplicativo. Um arquiteto de soluções precisa tornar a arquitetura do aplicativo mais escalável e altamente disponível com o MÍNIMO de tempo de inatividade. Qual solução atenderá a esses requisitos?

A adição de instâncias de leitura ao cluster Aurora distribui a carga de leitura, melhorando a escalabilidade e a disponibilidade para operações de leitura intensiva. O Amazon RDS Proxy reduz o tempo de failover para o Aurora em até 66% e gerencia eficientemente as conexões do banco de dados, o que é crucial para aplicações com alta carga de gravação e leitura, minimizando o tempo de inatividade. As outras opções são menos eficazes: EventBridge e Lambda podem monitorar o cluster, mas não escalam diretamente a capacidade de leitura/gravação nem melhoram o failover. O recurso de reinício sem tempo de inatividade (ZDR) é para atualizações de versão, não para escalabilidade de carga de trabalho. Database Activity Streams são para auditoria e conformidade, não para escalabilidade. ElastiCache for Redis é um excelente cache, mas o AWS DMS com abordagem write-around é complexo e pode introduzir latência ou inconsistência, não sendo a solução mais direta para o problema de escalabilidade e disponibilidade do banco de dados principal.