Mostly HarmlessState & fault tolerance

State TTL

State TTL expires idle keys, so state does not pile up until the 3am OOM.

Also called: time-to-live

State TTL - a time-to-live on state entries, the state TTL streaming jobs set so keys nobody has touched in a while get dropped instead of accumulating forever. It is the difference between a per-user aggregate that holds your active users and one that holds every user since launch, growing quietly until the job falls over at 3am.

Mechanically it is lazier than the name suggests. Flink stamps each entry with processing time and cleans expired ones on access, plus in the background during RocksDB compaction, so an expired entry can linger on disk after its deadline, invisible to reads but not yet gone. The guarantee says an expired value is never returned; the deletion itself can lag.

Do you need it? If you keep unbounded per-key state, yes, and set it on day one, because the keyspace grows for months before the bill lands. In ubik the common case expires itself: windowed state is freed when the watermark closes the window, so there is no TTL knob to remember. For an unwindowed GROUP BY, keyed state that outgrows the memory budget spills to disk rather than killing the process, though a keyspace that grows forever is still a keyspace that grows forever, in any engine.

Sources

Related