Status: IN
Data eviction timing varies across modules with no consistent strategy: message queue trims eagerly on every publish, rate limiter replaces its counter dict on each allowed request, URL shortener checks expiration lazily at read time, and the dedup registry prunes on watermark advance — each module independently decides when to reclaim old data, unlike other cross-cutting patterns (soft delete, time injection) where conventions exist.
Four different eviction triggers (write-time, access-time, read-time, watermark-time) with no shared pattern — a notable absence of convention in a codebase that otherwise favors them
Depends on (SL): dmq-retention-trimmed-on-publish, fixed-window-single-key-gc, url-shortener-expiration-lazy, dedup-pruning-uses-2x-lateness