Why this matters
- VaultCommerce runs Redis beside Postgres for sessions, rate limits, and hot product metadata — workloads that need sub-millisecond reads, not transactional joins.
- Understanding the single-threaded model explains why slow commands block everything and why you size instances by memory, not CPU cores alone.
- Redis 7.x adds functions, ACLs, and improved I/O threading for network handling — but command execution on the primary thread remains the mental anchor.
How Redis fits VaultCommerce
VaultCommerce's polyglot stack keeps orders in Postgres and pushes ephemeral, high-churn data to Redis:
VaultCommerce Redis roles
- Session store —
session:{token}strings with TTL after login. - Product cache — JSON blobs for catalog pages that tolerate brief staleness.
- Inventory counters — atomic
DECRon flash-sale SKUs without row locks in Postgres. - Rate limiting — sliding-window counters per IP and per API key.
Postgres remains the source of truth. Redis accelerates reads and absorbs write spikes that would otherwise hammer the primary database.
Single-threaded event loop
Redis accepts connections, reads commands, executes them atomically, and replies — all on one thread per shard. That design eliminates lock contention inside the engine and makes latency predictable.
# Inspect connected clients and command stats
redis-cli INFO clients
redis-cli INFO commandstats | head
Memory, keys, and eviction
Every value lives in RAM. Keys are binary-safe strings (up to 512 MB per value). When maxmemory is reached, Redis evicts keys per policy — typically allkeys-lru for pure cache workloads.
CONFIG GET maxmemory
CONFIG GET maxmemory-policy
SET product:SKU-8842 "{\"name\":\"Trail Pack\",\"price\":89}" EX 3600
TTL product:SKU-8842
Data types at a glance
Each Redis type maps to a backend pattern VaultCommerce uses daily:
Strings handle sessions and counters. Lists back lightweight job queues. Sets track unique tags. Sorted sets power leaderboards. Hashes store fielded objects. Streams provide durable event logs — covered in a later article.
Persistence and scale (preview)
Redis can survive restarts via RDB snapshots and AOF append logs. For high availability, Sentinel monitors primaries and promotes replicas; Cluster shards data across hash slots. VaultCommerce runs managed Redis in production rather than tuning these knobs by hand on day one — but you must know what each layer guarantees.
Quick recall
Everything you need if you only revisit this box.
- Redis is an in-memory data-structure server with a single-threaded command loop per shard.
- VaultCommerce uses Redis for sessions, caches, counters, and rate limits — Postgres stays authoritative.
- Keys expire via TTL; eviction policies matter when memory fills.
- Six core types: string, list, set, sorted set, hash, stream — each maps to a concrete pattern.
- Avoid blocking commands that scan the full keyspace in production.
- Persistence (RDB/AOF) and HA (Sentinel/Cluster) build on the in-memory core.
Test yourself
Answer these before moving on — recall is what makes it stick.