Un'azienda utilizza tracker GPS per documentare i modelli di migrazione di migliaia di tartarughe marine. I tracker controllano ogni 5 minuti e, se una tartaruga si è spostata di oltre 100 iarde (91,4 metri), inviano nuove coordinate a un'applicazione web in esecuzione su tre istanze Amazon EC2 in più Zone di Disponibilità in una Regione AWS. Recentemente l'applicazione web è stata sopraffatta da un volume inaspettato di dati dei tracker e i dati sono andati persi senza possibilità di riprodurre gli eventi. Un architetto di soluzioni deve impedire che ciò accada di nuovo con il minimo overhead operativo. Cosa dovrebbe fare l'architetto di soluzioni?

La risposta corretta è creare una coda Amazon SQS. Amazon SQS è un servizio di accodamento dei messaggi completamente gestito che disaccoppia i componenti dell'applicazione. In questo scenario, i tracker GPS possono inviare i dati a SQS, che li memorizza in modo affidabile fino a quando l'applicazione web non è pronta per elaborarli. Ciò impedisce la perdita di dati anche in caso di picchi di traffico, poiché SQS funge da buffer. L'applicazione web può quindi eseguire il polling della coda a un ritmo gestibile, garantendo che non venga sopraffatta. Questo approccio riduce al minimo l'overhead operativo in quanto SQS è un servizio serverless e scalabile. Creare un bucket Amazon S3 non è l'ideale perché S3 è uno storage di oggetti e non è progettato per la ricezione e l'elaborazione in tempo reale di flussi di dati. Un endpoint API Gateway con Lambda potrebbe funzionare, ma l'elaborazione di ogni elemento contemporaneamente con Lambda potrebbe essere costosa e non risolve direttamente il problema del sovraccarico dell'applicazione web esistente senza una coda. Creare una tabella DynamoDB per archiviare i dati e poi interrogare la tabella potrebbe funzionare, ma DynamoDB è un database NoSQL e l'uso di SQS è una soluzione più appropriata e con un overhead inferiore per la gestione di code di messaggi asincrone.