Un'azienda gestisce un'applicazione web per un marketplace online che serve centinaia di migliaia di utenti al picco. L'azienda necessita di una soluzione scalabile e quasi in tempo reale per condividere milioni di transazioni finanziarie con diverse applicazioni interne. Le transazioni devono essere elaborate per rimuovere i dati sensibili prima di essere archiviate in un database di documenti per un recupero a bassa latenza. Cosa dovrebbe raccomandare un architetto di soluzioni?

L'opzione corretta utilizza Amazon Kinesis Data Streams per l'ingestione di dati in tempo quasi reale e ad alto throughput, essenziale per milioni di transazioni. L'integrazione con AWS Lambda consente l'elaborazione immediata (rimozione dei dati sensibili) su ogni transazione non appena arriva nello stream, soddisfacendo il requisito di elaborazione "quasi in tempo reale". Successivamente, i dati elaborati vengono archiviati in Amazon DynamoDB, un database di documenti NoSQL per un recupero a bassa latenza. Altre applicazioni possono consumare i dati direttamente dal Kinesis Data Stream, garantendo una condivisione efficiente. Le altre opzioni sono meno adatte: Archiviare direttamente in DynamoDB e usare regole per rimuovere dati sensibili non è l'approccio più scalabile o flessibile per l'elaborazione in tempo reale di milioni di transazioni e la condivisione con più applicazioni. DynamoDB Streams è per la cattura delle modifiche, non per l'elaborazione intermedia. Kinesis Data Firehose è ottimizzato per il caricamento in batch su destinazioni come S3 o Redshift, non per l'elaborazione record per record in tempo quasi reale e la condivisione diretta dello stream con altre applicazioni. L'archiviazione in batch su S3 introduce latenza significativa e non soddisfa il requisito di elaborazione "quasi in tempo reale".