Before shipping it, separate protocol facts, product promises, and operating cost. Mixing those layers produces confident but incorrect decisions. Most TTL cleanup is approximate. Reads enforce expiresAt immediately for logical invisibility, while background deletion reclaims space.
Data design covers atomic writes, concurrent access, schema migration, crash recovery, and cleanup. One successful save says nothing about power loss, full storage, or reopening with an older version.
The parts that make the design practical
Write the following choices as reviewable rules instead of scattering them across callbacks and UI conditions. Explicit rules make scaling, compatibility, and diagnosis less dependent on guesswork.
- Lead an index with expiresAt, delete stable primary-key batches under rate limits, emit deletion events to caches, and monitor oldest expired age plus backlog.
- Give state one owner, a version, and terminal states; callbacks may mutate only the version that created them.
- Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.
The delivery standard for TTL Indexes and Expiration Jobs Do Not Delete at the Deadline is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Keep false assumptions out of production
Boundaries turn hidden assumptions into incidents. Weak networks, refresh, concurrency, and capacity need combined coverage because retries can hide each one in isolation.
- Deleting all expired rows at once locks tables, inflates WAL, and lags replicas, while filter-only expiry grows disk until full.
- Refresh and network change start two recovery paths, and duplicate side effects look like two genuine user actions.
- Without backpressure or quota, a slow consumer raises memory, queue depth, and tail latency until unrelated users are affected.
What the release gate should inspect
Do not stop verification when the final action succeeds. Count side effects, measure wait time, inspect privacy, and prove the next run begins from a clean baseline.
- Preload one hundred million simultaneous and uniform expiries, run cleanup under traffic, and verify logical invisibility, batch latency, replication lag, and disk reclamation.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Before release, record success rate, p50/p95/p99 latency, error classes, and resource high-water marks with explicit rollback thresholds.
The release bar is clear: users understand the current state, failures stop or recover, resources stay bounded, and operators can identify the phase from minimum necessary evidence.