Redis

How Tracera uses Redis for caching, pub/sub, and sessions

Redis

Redis serves multiple roles in Tracera, handling everything from caching to real-time message broadcasting.

Roles

Role	Data Structure	Purpose
Price Cache	String/Hash	Latest prices for instant reads
Pub/Sub	Channels	Broadcasting price and volatility updates
Volatility Rankings	Sorted Sets	Ranked list of most volatile items
Session Store	String	SCS session data with TTL
Rate Limiting	String (counter)	Per-IP request counters with TTL
Magic Link Tokens	String	One-time-use tokens with 10-minute TTL
Import Cooldown	String	Per-user portfolio import cooldown

Price Caching

On every ingestion cycle, the latest price for each item is cached in Redis:

Key:   price:latest:{item_id}
Value: {price_json}
TTL:   Refreshed on each ingestion cycle

This enables sub-millisecond price lookups without hitting TimescaleDB.

Pub/Sub Channels

Price and volatility updates are published to Redis channels for real-time delivery:

Channel: prices     — new price data from ingestion
Channel: volatility — recomputed volatility metrics

The WebSocket hub subscribes to these channels and fans out updates to connected clients.

Volatility Rankings

The most volatile items are stored in a Redis sorted set:

Key:    rankings:volatile
Member: {item_id}
Score:  {volatility_score}

Sorted sets enable O(log N) ranked queries — perfect for “most volatile items” leaderboards.

Session Storage

SCS stores session data in Redis with automatic TTL:

Key:   session:{session_id}
Value: {session_data}
TTL:   72 hours (configurable)

Configuration

REDIS_HOST=localhost    # Redis host
REDIS_PORT=6379         # Redis port
REDIS_PASSWORD=         # Optional password
REDIS_DB=0              # Database index (0-15)

Connection Pooling

The backend uses pooled Redis connections shared across cache reads, pub/sub, and session lookups to avoid connection overhead.