Eliminating Stale Market Regime Data with Redis TTL Enforcement

Argus computes market regime classifications across 8 timeframes for every active symbol in its universe. The regime service runs a classification cycle, reads feature vectors from Redis, applies a 5-class classifier, and writes results back as Redis hashes. Apex, the execution layer, reads those keys before sizing any position.

The problem was subtle and dangerous: nothing enforced a TTL on regime keys. The write path called redis.hset_multiple() to write the classification hash, then stopped. No EXPIRE call followed. If argus-regime stopped or fell behind, its last classification persisted indefinitely. Apex would read a regime label that could be hours or days old and apply position sizing and risk gates as if the regime were current.

An audit on April 25, 2026 confirmed the scope: 209,033 regime keys in Redis, all with TTL of -1 (permanent). The system had been running for weeks accumulating stale potential.

The fix needed to operate at two levels. The immediate remediation covered the existing 209,033 stale keys. The permanent fix embedded TTL enforcement directly into the writer so no future key could ever be written without an expiry.

For the remediation sweep, a naive KEYS argus:regime:* was ruled out immediately. Redis KEYS is O(N) and blocks the server for the duration of the scan. With 209K matching keys in a production database also serving live feature reads, a blocking scan would have caused latency spikes in Apex's regime reads. Instead, the sweep used iterative SCAN with a cursor and a count of 200 per batch. Each batch set TTL with EXPIRE key 86400. The full sweep completed without measurable impact on Redis latency.

For the permanent fix, the choice was 86400 seconds (24 hours). A 1-hour TTL would surface stale-regime bugs faster, but the regime pipeline runs on a configurable interval and a transient delay of several minutes could cause unnecessary key expiration during normal operation.

The EXPIRE call follows hset_multiple in the same async context. If hset_multiple succeeds but EXPIRE fails, the key exists without a TTL. That was accepted as tolerable given Redis 7.2 reliability on localhost: in the failure scenario, the health writer would mark the cycle as degraded before the stale key aged past 24 hours. Complete atomicity via a pipeline or a Lua script was considered but rejected as over-engineering for a single-host configuration.

The regime collection cache at the /api/intelligence/regime route was the bigger win. The original route iterated over all 209,033 Redis regime keys using a SCAN loop to build a regime summary. SCAN on 209,033 keys took 1,048ms even with Redis's non-blocking approach, because the collection traversal was synchronous from the API route's perspective. The fix was a single pre-aggregated cache key updated by the regime pipeline after every write cycle. Instead of scanning 209,033 keys per request, each request performed a single GET. Latency dropped from 1,048ms to 79 to 90ms.

Before the fix: 209,033 keys, 0 with TTL, 100% permanent. After the SCAN sweep: 209,033 keys, all with TTL approximately 86,400 seconds. The sweep ran in under 4 minutes on a server with Redis 7.2 running at roughly 4,000 operations per second for active ingest.

The /api/macro route demonstrated the performance model. Cold-cache latency measured at 1,476ms. Warm-cache latency measured at 465ms. A 3.2x improvement for the most common repeated query pattern. Regime hash reads via hgetall on a warm key return in under 5ms versus 40 to 80ms for a ClickHouse fallback.