Using Redis to Cache Open Orders in a Live Trading Bot

Redis is best used as an execution state layer, not a source of market truth. The exchange remains source of truth; Redis gives you fast local decisions and resilient workflow coordination.

Practical Key Design

# Hash of active order fields
HSET order:binance:12345 symbol BTC/USDT side buy status open filled 0.0

# Sorted set for open order ids by timestamp
ZADD open_orders:binance 1700000000 12345

# Stream for execution events
XADD fills:binance * order_id 12345 qty 0.01 price 65123.5

Consistency Model

• Write through: update Redis only after exchange acknowledgement.
• Periodic reconciliation: compare Redis state to exchange snapshots.
• Dead-letter queue for malformed or delayed events.
• Expiry policies for stale keys to prevent memory bloat.

Operational Guardrails

• Track cache hit ratio and reconciliation drift as first-class alerts.
• Use atomic pipelines or Lua scripts for multi-key updates.
• Keep Redis persistence tuned for recovery, not just speed.
• Separate critical execution keys from analytics workloads.