Un'azienda ospita un'applicazione su funzioni AWS Lambda invocate da un'API Amazon API Gateway. Le funzioni Lambda salvano i dati dei clienti in un database Amazon Aurora MySQL. Ogni volta che l'azienda aggiorna il database, le funzioni Lambda non riescono a stabilire le connessioni al database fino al completamento dell'aggiornamento, causando la perdita dei dati dei clienti per alcuni eventi. Un architetto di soluzioni deve progettare una soluzione che memorizzi i dati dei clienti creati durante gli aggiornamenti del database. Quale soluzione soddisferà questi requisiti?

La soluzione corretta è memorizzare i dati dei clienti in una coda FIFO di Amazon SQS e utilizzare una funzione Lambda separata per elaborare la coda. Questo approccio disaccoppia il processo di scrittura dei dati dalla disponibilità del database Aurora. Durante gli aggiornamenti del database, i dati vengono accodati in modo affidabile e possono essere elaborati una volta che il database è di nuovo disponibile, prevenendo la perdita di dati. Il provisioning di un proxy Amazon RDS (opzione 1) può aiutare a gestire le connessioni, ma non risolve intrinsecamente il problema della disponibilità del database durante gli aggiornamenti, poiché il proxy inoltra comunque le richieste al database sottostante. Aumentare il tempo di esecuzione di Lambda e implementare retry (opzione 2) non garantisce la persistenza dei dati se il database è indisponibile per un periodo prolungato e potrebbe comunque portare a timeout o errori. La persistenza dei dati nell'archiviazione locale di Lambda (opzione 3) non è affidabile, poiché l'archiviazione locale è effimera e non garantisce la persistenza tra le invocazioni o in caso di guasto della funzione.