DynamoDB Streams: la guida completa (con esempi)

DynamoDB Streams è un log di change-data-capture: ogni insert, update e delete su una tabella viene catturato, in ordine, come uno stream di record a cui puoi reagire. È il modo in cui trasformi una tabella in una sorgente di eventi senza fare polling.

Nello scenario dell'audit-log vuoi reagire nell'istante in cui arriva un evento sensibile — lanciare un alert quando qualcuno esporta una fattura o concede un ruolo di admin — senza scansionare la tabella a intervalli. Streams è il lato push di questo.

Come funziona DynamoDB Streams?

DynamoDB Streams cattura ogni insert, update e delete su una tabella come un log di record ordinato nel tempo e deduplicato, conservato fino a 24 ore. Scegli cosa porta ciascun record con StreamViewType (keys, new image, old image o entrambi), poi consumi lo stream con un trigger Lambda per reagire alle modifiche degli item senza fare polling.

• Streams cattura le modifiche a livello di item come un log ordinato nel tempo e deduplicato, conservato fino a 24 ore.
• Scegli cosa porta ciascun record tramite StreamViewType: solo le chiavi, la new image, la old image, oppure sia la vecchia sia la nuova.
• I record sono ordinati per item — le modifiche a un singolo item arrivano nell'ordine in cui sono state scritte — e uno stream è shardato allo stesso modo della tabella.
• Il consumer nativo è Lambda — un trigger che viene eseguito per ogni batch di nuovi record, con Kinesis Data Streams come alternativa per un fan-out più ricco.

Il problema: reagire senza fare polling

Ti serve "avvisami quando viene scritto un evento role.granted." L'approccio ingenuo è un job schedulato che scansiona nuovi eventi ogni minuto — il che legge l'intera partizione recente ogni volta, costa capacità ed è sempre in ritardo di almeno un minuto.

Ciò che vuoi davvero è un push: DynamoDB ti dice nel momento in cui un item cambia. È esattamente ciò che Streams fornisce, con il record di modifica consegnato al tuo codice invece di doverlo cercare tu.

Come funziona Streams

Secondo la documentazione AWS, DynamoDB Streams mantiene un log deduplicato e ordinato nel tempo delle modifiche fino a 24 ore, con integrazione nativa con Lambda (change data capture per DynamoDB). Ogni record descrive una modifica a livello di item.

Quando abiliti uno stream scegli uno StreamViewType, che controlla quanta parte dell'item modificato porta ciascun record:

I record sono ordinati per item — le modifiche a un singolo item compaiono nell'ordine in cui sono state scritte — e lo stream è shardato lungo la stessa struttura di partizione della tabella. La conservazione è di 24 ore — Streams è un buffer di reazione, non uno storico permanente. Per uno storico durabile memorizzi gli eventi stessi (che è esattamente ciò che la nostra tabella di audit-log già è).

Il consumer nativo è un trigger Lambda: DynamoDB invoca la tua funzione con un batch di nuovi record di stream man mano che arrivano.

Un esempio pratico: alert su eventi di audit sensibili

La tabella di audit-log ottiene uno stream con NEW_IMAGE, così che ciascun record porti l' intero nuovo evento. Una Lambda consuma il batch e inoltra solo i record che contano:

La funzione non tocca mai la tabella — reagisce esclusivamente a ciò che lo stream le consegna. Nessun polling, nessuno scan, e l'alert scatta entro pochi secondi dalla scrittura. I record dello stream sono ordinati per item, quindi le modifiche successive allo stesso item-evento arrivano nell'ordine in cui sono state scritte.

Questo è anche il modo standard per mantenere una copia a valle: un consumer di stream può proiettare ciascun evento in OpenSearch per la ricerca full-text sull'audit, oppure aggregare conteggi — il tutto derivato dallo stesso change log.

Fallo in DynoTable

Prima di collegare un consumer di stream, devi conoscere la forma esatta dell' item che la tua Lambda riceverà — quali attributi esistono, come appaiono mappe e liste annidate, cosa conterrà effettivamente un record NEW_IMAGE.

Per convertire un item di esempio tra il JSON semplice e la forma attribute-value che un record di stream usa, il Convertitore DynamoDB JSON lo fa nel tuo browser. E in DynoTable puoi ispezionare l'item completo — inclusa la sua forma DynamoDB-JSON — così da modellare il record NEW_IMAGE su dati reali invece di indovinare la forma dei campi.

Se stai testando un consumer localmente, esegui la tabella su DynamoDB Local e ispezionala allo stesso modo — vedi connettersi a DynamoDB Local.

Insidie e passaggi successivi

• 24 ore non sono un backlog. Se il tuo consumer è down per un giorno, i record scadono e spariscono. Streams è per la reazione quasi in tempo reale, non per il replay durabile — conserva gli eventi stessi per lo storico.
• Scegli il più piccolo StreamViewType che ti serve. NEW_AND_OLD_IMAGES raddoppia il payload; se ti serve solo la chiave per andare a rileggere l'item, KEYS_ONLY è più economico.
• L'ordinamento è per item, non per chiave di partizione né globale. DynamoDB garantisce l'ordine solo per le modifiche successive allo stesso item; non c'è alcuna garanzia di ordine tra item diversi, nemmeno all'interno di una stessa chiave di partizione.
• Le delete di TTL compaiono come record di stream con il marcatore di attributo di sistema, il che è il modo in cui archivi gli item in scadenza — vedi DynamoDB TTL.

Streams trasforma l'audit log in una sorgente di eventi. La prossima preoccupazione operativa è l'estremità opposta della vita di un item — far scadere automaticamente i vecchi eventi con DynamoDB TTL.

Scarica DynoTable per ispezionare la forma esatta dell'item che il tuo consumer di stream riceverà prima di scrivere una riga di codice Lambda.