DynamoDB Streams

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. È così che trasformi una tabella in una sorgente di eventi senza fare polling.

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

Come funziona DynamoDB Streams?

DynamoDB Streams cattura ogni insert, update e delete su una tabella come un log ordinato nel tempo e deduplicato, conservato fino a 24 ore. Scegli cosa porta ogni record tramite StreamViewType (solo le chiavi, l'immagine nuova, quella vecchia, o entrambe), 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 ogni record tramite StreamViewType: solo le chiavi, l'immagine nuova, quella vecchia, o entrambe.
• I record sono ordinati all'interno di una partition key, e uno stream è partizionato allo stesso modo della tabella.
• Il consumer nativo è Lambda — un trigger che gira per ogni batch di nuovi record, con Kinesis Data Streams come alternativa per un fan-out più ricco.

Il problema: reagire senza polling

Ti serve "avvisami quando viene scritto un evento role.granted." L'approccio ingenuo è un job schedulato che scansiona i 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 costringerti a cercarlo.

Come funziona Streams

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

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

I record sono ordinati all'interno di ciascuna partition key e lo stream è partizionato secondo la stessa struttura di partizione della tabella. La conservazione è di 24 ore — Streams è un buffer di reazione, non uno storico permanente. Per uno storico durevole conservi 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 sugli eventi di audit sensibili

La tabella di audit-log riceve uno stream con NEW_IMAGE, così ogni record porta l'evento nuovo completo. Una Lambda consuma il batch e inoltra solo i record che contano:

La funzione non tocca mai la tabella — reagisce puramente a ciò che lo stream le passa. Niente polling, nessuna Scan, e l'alert scatta entro pochi secondi dalla scrittura. Poiché i record sono ordinati per partition key, tutti gli eventi di un tenant arrivano nell'ordine in cui sono stati scritti.

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

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à davvero un record NEW_IMAGE.

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

Se stai testando un consumer in locale, esegui la tabella contro DynamoDB Local e ispezionala allo stesso modo — vedi connessione a DynamoDB Local.

Trappole e prossimi passi

• 24 ore non sono un backlog. Se il tuo consumer resta giù per un giorno, i record invecchiano e spariscono. Streams serve per la reazione in near-real-time, non per il replay durevole — conserva gli eventi stessi per lo storico.
• Scegli il StreamViewType più piccolo 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 partition key, non globale. Gli eventi di due tenant diversi non hanno alcuna garanzia di ordinamento tra loro — solo all'interno della partizione di un singolo tenant.
• Le delete da TTL compaiono come record di stream con il marker di attributo di sistema, ed è così che archivi gli Item in scadenza — vedi DynamoDB TTL.

Streams trasforma l'audit-log in una sorgente di eventi. La prossima preoccupazione operativa è l'estremo opposto 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.