Een e-commercebedrijf draait zijn applicatie op AWS. De applicatie gebruikt een Amazon Aurora PostgreSQL-cluster in Multi-AZ-modus voor de database. Tijdens een recente promotiecampagne ondervond de applicatie een zware lees- en schrijfbelasting. Gebruikers ondervonden time-outproblemen bij het openen van de applicatie. Een solutions architect moet de applicatiearchitectuur schaalbaarder en zeer beschikbaar maken met de MINSTE downtime. Welke oplossing voldoet aan deze vereisten?

De juiste oplossing is om extra reader instances toe te voegen aan het Aurora-cluster en een Amazon RDS Proxy-doelgroep aan te maken. Extra reader instances verhogen de leescapaciteit en verbeteren de beschikbaarheid door failover-doelen te bieden. RDS Proxy vermindert de overhead van het openen van verbindingen, beheert verbindingen efficiënt en verbetert de failover-tijden, wat essentieel is voor minimale downtime en schaalbaarheid onder zware belasting. De andere opties zijn minder geschikt: EventBridge met Lambda voor het loggen van statuswijzigingen helpt bij monitoring, maar lost de schaalbaarheids- en beschikbaarheidsproblemen niet direct op. Het toevoegen van reader nodes is correct, maar de EventBridge-component is niet de primaire oplossing voor de gestelde problemen. Zero-downtime restart (ZDR) is voor onderhoud en lost geen prestatieproblemen op tijdens piekbelasting. Database Activity Streams is voor auditing, niet voor prestatieverbetering. ElastiCache for Redis kan leesprestaties verbeteren, maar het repliceren van gegevens met AWS DMS en een write-around-benadering is complex, voegt latentie toe voor writes en is niet de meest directe oplossing voor de primaire schaalbaarheid en beschikbaarheid van de database zelf.