Een bedrijf host een applicatie op AWS Lambda-functies die worden aangeroepen door een Amazon API Gateway API. De Lambda-functies slaan klantgegevens op in een Amazon Aurora MySQL-database. Telkens wanneer het bedrijf de database upgrade, kunnen de Lambda-functies geen databaseverbindingen tot stand brengen totdat de upgrade is voltooid, wat leidt tot verlies van klantgegevens voor sommige gebeurtenissen. Een solutions architect moet een oplossing ontwerpen die klantgegevens opslaat die zijn aangemaakt tijdens database-upgrades. Welke oplossing voldoet aan deze vereisten?

De juiste oplossing is het opslaan van klantgegevens in een Amazon SQS FIFO-wachtrij. Wanneer de database niet beschikbaar is tijdens upgrades, kunnen de Lambda-functies de gegevens naar de SQS-wachtrij sturen. Een aparte Lambda-functie kan vervolgens de wachtrij pollen en de gegevens naar de database schrijven zodra deze weer online is. Dit voorkomt gegevensverlies en zorgt voor een asynchrone verwerking. Het provisioneren van een Amazon RDS Proxy helpt bij het beheren van databaseverbindingen en het multiplexen ervan, maar lost het probleem van een onbeschikbare database tijdens upgrades niet op. Het verhogen van de Lambda-runtime en het toevoegen van een retry-mechanisme is geen robuuste oplossing, omdat retries uiteindelijk zullen falen als de database langere tijd offline is. Klantgegevens persistent maken in de lokale opslag van Lambda is onbetrouwbaar, omdat de levenscyclus van de Lambda-instantie niet gegarandeerd is en gegevens verloren kunnen gaan.