De API van een bedrijf ontvangt real-time gegevens van monitoringapparaten en slaat deze op in een Amazon RDS DB-instantie. Het inkomende gegevensvolume fluctueert en tijdens druk verkeer treedt er een time-out op in de API omdat de database het schrijfvolume niet kan verwerken. Een solutions architect moet databaseverbindingen minimaliseren en zorgen voor geen gegevensverlies tijdens druk verkeer. Welke oplossing voldoet aan deze vereisten?

De correcte oplossing is het wijzigen van de API om inkomende gegevens naar een Amazon SQS-wachtrij te schrijven, en een AWS Lambda-functie te gebruiken om deze gegevens van de wachtrij naar de database te schrijven. Dit ontkoppelt de API van de database, waardoor de API snel kan reageren en de gegevens in de SQS-wachtrij worden gebufferd. Lambda kan de gegevens vervolgens in een beheersbaar tempo naar de database schrijven, waardoor time-outs en gegevensverlies tijdens piekbelasting worden voorkomen en het aantal databaseverbindingen wordt geminimaliseerd. Het vergroten van de DB-instantie kan de prestaties verbeteren, maar lost het probleem van fluctuerend verkeer en potentiële overbelasting niet structureel op. Een Multi-AZ DB-instantie verhoogt de beschikbaarheid, niet de schrijfcapaciteit, en het schrijven naar alle actieve instanties is geen standaardpatroon voor RDS en kan leiden tot inconsistenties. Amazon SNS is een public/subscribe-service en is niet geschikt voor het bufferen van berichten voor latere verwerking zoals SQS dat wel is.