Un'applicazione utilizza una funzione AWS Lambda (richiamata tramite Amazon API Gateway) per archiviare i dati in un database Amazon Aurora PostgreSQL. Durante la fase di proof-of-concept, l'azienda ha aumentato le quote Lambda per gestire carichi di dati ad alto volume. Un architetto di soluzioni deve raccomandare un design che migliori la scalabilità e minimizzi lo sforzo di configurazione. Quale soluzione soddisfa questi requisiti?

La soluzione corretta prevede l'uso di Amazon SQS per desacoppiare il processo di ricezione dei dati da quello di caricamento nel database. La prima funzione Lambda riceve i dati e li inserisce in una coda SQS, che funge da buffer. La seconda funzione Lambda legge i messaggi dalla coda e li scrive nel database Aurora PostgreSQL. Questo approccio migliora la scalabilità perché SQS gestisce automaticamente picchi di traffico, permettendo alle funzioni Lambda di elaborare i dati a un ritmo sostenibile senza superare le quote o sovraccaricare il database. Minimizza lo sforzo di configurazione grazie alla natura gestita di SQS. Le altre opzioni sono meno ideali: Rifattorizzare in EC2 aumenta la complessità operativa e non migliora necessariamente la scalabilità in modo automatico come le soluzioni serverless. Cambiare database in DynamoDB e usare DAX è un refactoring significativo che non minimizza lo sforzo di configurazione e potrebbe non essere adatto se le esigenze relazionali di PostgreSQL sono fondamentali. Usare Amazon SNS non è l'ideale per il buffering di messaggi persistenti e l'elaborazione asincrona a lungo termine, come richiesto per il caricamento di dati, poiché SNS è più adatto per la notifica push.