L'API di un'azienda riceve dati in tempo reale da dispositivi di monitoraggio e li archivia in un'istanza DB di Amazon RDS. Il volume di dati in ingresso fluttua e durante il traffico intenso l'API va in timeout perché il database non riesce a elaborare il volume di scrittura. Un architetto di soluzioni deve ridurre al minimo le connessioni al database e garantire l'assenza di perdita di dati durante il traffico intenso. Quale soluzione soddisfa questi requisiti?

La soluzione corretta utilizza Amazon SQS come buffer per gestire i picchi di traffico. L'API scrive i dati nella coda SQS, che può assorbire grandi volumi di messaggi senza perdere dati. Una funzione AWS Lambda viene quindi invocata da SQS per elaborare i messaggi e scrivere i dati nel database RDS a un ritmo controllato, evitando timeout e sovraccarichi. Questo disaccoppia l'API dal database, migliorando la resilienza. Aumentare la dimensione dell'istanza DB potrebbe non risolvere il problema dei picchi di scrittura e sarebbe più costoso. Un'istanza Multi-AZ migliora la disponibilità ma non la capacità di scrittura per un singolo database. Amazon SNS non è ideale per questo caso d'uso perché è un servizio di pubblicazione/sottoscrizione che non offre la persistenza e la garanzia di consegna "almeno una volta" di SQS per i messaggi da elaborare.