DynamoDB TTL

Il Time to Live (TTL) lascia che DynamoDB cancelli gli Item automaticamente una volta superato un timestamp che memorizzi su di essi. Indichi un attributo che contiene una scadenza Unix-epoch, e DynamoDB raccoglie gli Item scaduti in background — niente job di reaper, nessun costo extra.

Nello scenario dell'audit-log ogni tenant ha una policy di retention: tenere gli eventi per 90 giorni, o 1 anno, o 7 per quelli ad alta compliance. Il TTL è il modo per applicarla senza far girare la tua sweep di delete.

Come funziona il TTL di DynamoDB?

Il TTL di DynamoDB cancella automaticamente gli Item una volta superato un timestamp Unix-epoch (secondi) che memorizzi in un attributo designato. Abiliti il TTL sulla tabella, indichi l'attributo di scadenza, e DynamoDB raccoglie gli Item scaduti in background — tipicamente entro 48 ore, senza consumare capacità di scrittura. Gli Item scaduti rimangono leggibili finché non vengono fisicamente cancellati.

• Il TTL è un attributo che contiene un timestamp Unix-epoch (secondi). Quando quel momento passa, l'Item diventa eleggibile per la cancellazione.
• La cancellazione è in background e best-effort — tipicamente entro un paio di giorni dalla scadenza, non il secondo esatto. AWS punta a entro 48 ore.
• Le delete da TTL sono gratuite — non consumano capacità di scrittura.
• Gli Item scaduti ma non ancora cancellati appaiono comunque nelle letture, quindi filtra sull'attributo di scadenza se devi nasconderli immediatamente.

Il problema: far scadere i vecchi dati da soli è costoso

Senza TTL, applicare "scarta gli eventi più vecchi di 90 giorni" significa far girare il tuo reaper: scansionare (o fare query per) i vecchi Item su uno scheduler e fare DeleteItem su ciascuno. Quella Scan brucia capacità di lettura, le delete bruciano capacità di scrittura, e tu possiedi lo scheduler, i fallimenti e i retry.

Per un audit-log ad alto volume è una tassa costante e crescente solo per buttare via dati. Il TTL sposta l'intero lavoro dentro DynamoDB, gratuitamente.

Come funziona il TTL

Abiliti il TTL su una tabella e le dici quale attributo contiene la scadenza. Secondo l'annuncio AWS, "specifichi un attributo dell'Item che contiene un timestamp di scadenza Unix epoch, e DynamoDB gestisce la cancellazione automaticamente in background — senza influenzare le prestazioni della tabella."

Due proprietà contano per la correttezza:

• È best-effort, non esatto. DynamoDB scansiona gli Item scaduti e li cancella in background; AWS punta alla cancellazione entro 48 ore dalla scadenza. Un Item è eleggibile al suo timestamp ma può indugiare brevemente.
• Gli Item scaduti sono ancora leggibili finché non vengono raccolti. Una Query può restituire un Item il cui TTL è passato ma che non è ancora stato cancellato — quindi aggiungi una FilterExpression sull'attributo di scadenza se "scaduto = invisibile immediatamente" è un requisito rigido.

E le delete da TTL non consumano capacità di scrittura, ed è ciò che le rende strettamente più economiche di un reaper gestito in proprio.

Un esempio pratico: retention per tenant

Ogni evento di audit porta un attributo expiresAt impostato quando l'evento viene scritto — now + la finestra di retention del tenant, in secondi epoch:

Il TTL è abilitato con expiresAt come attributo TTL. Quando l'evento a 90 giorni di acme supera 1758873600, DynamoDB lo cancella da solo entro circa due giorni. Gli eventi del tenant di compliance portano un expiresAt lontano nel futuro, quindi sopravvivono — stessa tabella, stesso meccanismo, retention diversa per Item.

Il lato scrittura è solo aggiungere un numero quando crei l'evento. Puoi comporre la clausola SET expiresAt = :ttl e verificare il valore tipizzato :ttl nel DynamoDB Expression Builder.

Per nascondere immediatamente da una lettura un evento scaduto ma non raccolto, aggiungi expiresAt > :now alla FilterExpression della query — ma ricorda che un filtro non riduce il costo di lettura (Query vs Scan).

Fallo in DynoTable

Il classico bug del TTL è un expiresAt sbagliato: memorizzato in millisecondi invece che secondi, o come stringa ISO, così l'Item o non scade mai o svanisce immediatamente. L'unico modo per coglierlo è guardare il valore effettivamente memorizzato e il suo tipo.

DynoTable mostra gli attributi di ogni Item con i loro tipi DynamoDB, così puoi confermare che expiresAt sia un Number in secondi epoch — non una String, non millisecondi — prima di affidare al TTL una retention reale.

Trappole e prossimi passi

• Secondi epoch, come Number. Questo è l'errore di TTL più comune in assoluto. Un valore in millisecondi spinge la scadenza a ~50.000 anni nel futuro; una stringa ISO viene ignorata del tutto. Verifica il tipo e l'unità.
• Non fare affidamento sul timing della cancellazione. Fino a ~48 ore possono passare tra scadenza e cancellazione. Se "sparito nell'istante in cui scade" conta, filtra sull'attributo nelle letture; non assumere che la riga sia fisicamente sparita.
• Le delete da TTL appaiono in Streams. Una cancellazione da TTL emette un record di stream marcato come generato dal sistema — l'hook standard per archiviare gli eventi in scadenza su S3 prima che spariscano. Vedi DynamoDB Streams.
• Le delete da TTL colpiscono comunque i GSI. Rimuovere un Item lo rimuove anche da qualunque Index secondario in cui si trovava — è la pulizia voluta, ma vale la pena saperlo se un Index pilotava un conteggio.

Il TTL gestisce la fine della vita di un evento a poco prezzo. La prossima domanda è cosa paghi per le scritture in primo luogo — capacità On-Demand vs con provisioning.

Scarica DynoTable per ispezionare i tipi degli attributi dei tuoi Item e confermare che il tuo attributo TTL sia un Number Unix-epoch prima di attivare il TTL.