Una startup meteorologica utilizza Amazon DynamoDB per archiviare i dati meteorologici e desidera un nuovo servizio che notifichi i responsabili di quattro team interni ogni volta che viene registrato un nuovo evento meteorologico. L'azienda non vuole che il nuovo servizio influisca sulle prestazioni attuali dell'applicazione e desidera il minor overhead operativo. Cosa dovrebbe fare un architetto di soluzioni?

Abilitare DynamoDB Streams e configurare un trigger (come una funzione AWS Lambda) per scrivere su un singolo argomento SNS è la soluzione migliore perché disaccoppia la logica di notifica dall'applicazione principale, evitando impatti sulle prestazioni. DynamoDB Streams fornisce un flusso ordinato di modifiche a livello di elemento, garantendo che ogni nuovo evento meteorologico venga catturato. Un trigger Lambda può quindi elaborare questi eventi e pubblicarli su un argomento SNS, a cui tutti e quattro i team possono sottoscriversi per ricevere notifiche. Questo approccio è serverless, riducendo l'overhead operativo. Le transazioni DynamoDB non sono adatte per le notifiche esterne e non sono progettate per questo scopo. Far pubblicare all'applicazione messaggi su quattro argomenti SNS separati aumenterebbe la complessità dell'applicazione e il suo carico di lavoro. Un cron job che esegue la scansione della tabella è inefficiente, costoso e introduce latenza, oltre a non essere scalabile.