Transient traffic incidents should disappear from a hot operational store after a set period without manual cleanup jobs. Which NoSQL operational feature fits this need?
Select an answer to reveal the explanation.
Short Explanation
Old fender-bender alerts should fade out on their own—that is TTL. Set an expiration and the hot store cleans itself. No nightly clerk with a delete key required.
Full Explanation
Transient traffic incidents that should vanish after a set period without manual cleanup map cleanly to TTL (time-to-live) features that auto-expire records in the hot operational store. That keeps the hot tier focused on current incidents. Permanent immutable retention of every incident forever in the hot tier bloats latency-sensitive storage and confuses hot operations with archival history. Requiring clerks to delete each incident by hand each night does not scale and fails when shifts are busy. Disabling all deletes so the hot store grows without bound eventually harms performance and cost. Exam caveat: TTL is for transient operational state; durable incident archives for after-action review belong in a lake or warehouse with explicit retention policy. Operational check: write a test incident with a short TTL in staging, wait for expiry, confirm it disappears from the hot store, and verify the archival pipeline still captured a copy if policy requires history. In production terms for TTL for transient traffic incidents, assign an owning team, wire a dashboard that shows the pattern is healthy under peak civic load, and require a staging drill that rehearses failure and recovery before resident impact. Revisit the choice when traffic shape, retention, or integrity needs change, and keep a named rollback owner on the change record. Re-test both the happy path and the failure path for TTL for transient traffic incidents after material dependency upgrades so regressions are caught before the next public release.