Why this matters
- VaultCommerce started with Memcached for HTML fragments, then migrated sessions and carts to Redis for TTL semantics and atomic operations.
- Picking Redis for pure byte caching wastes memory on features you never enable; picking Memcached when you need sorted sets forces awkward workarounds.
- Interviews compare the two with concrete VaultCommerce use cases, not feature checklists.
Memcached strengths
When Memcached fits
- Simple model — opaque key → byte array; no data types to learn.
- Multi-threaded — scales vertically on large machines without cluster complexity.
- Memory efficient — slab allocator reduces fragmentation for uniform object sizes.
- Stateless — losing a node means cache miss, not data loss (if DB is truth).
# Memcached: pure get/set
mc.set(b"fragment:homepage", rendered_html, expire=300)
html = mc.get(b"fragment:homepage")
VaultCommerce still uses Memcached for rendered category HTML fragments — large, uniform blobs with no need for lists, hashes, or pub/sub.
Redis strengths
When Redis fits
- Rich types — strings, lists, sets, sorted sets, hashes, streams.
- Atomic operations —
INCR,HINCRBY,LPUSHwithout race conditions. - Persistence — RDB snapshots and AOF for durability when needed.
- Replication and cluster — HA, failover, horizontal sharding.
- Pub/Sub and streams — lightweight messaging between services.
HSET cart:user_42 items "[{\"sku\":\"VC-HP-BLK\",\"qty\":1}]"
HINCRBY product:8842:views 1
ZADD leaderboard:sales 14999 "VC-HP-BLK"
VaultCommerce carts, sessions, rate limiters, and leaderboards live in Redis — operations that Memcached cannot express without application-level locking.
Side-by-side comparison
| Aspect | Memcached | Redis |
|---|---|---|
| Threading | Multi-threaded | Single-threaded (I/O threads in 7.x) |
| Data model | Opaque blobs | Structured types |
| Persistence | None | RDB + AOF |
| HA | Client-side hashing only | Sentinel + Cluster |
| VaultCommerce role | HTML fragment cache | Sessions, carts, counters |
Threading
MemcachedMulti-threadedRedisSingle-threaded (I/O threads in 7.x)Data model
MemcachedOpaque blobsRedisStructured typesPersistence
MemcachedNoneRedisRDB + AOFHA
MemcachedClient-side hashing onlyRedisSentinel + ClusterVaultCommerce role
MemcachedHTML fragment cacheRedisSessions, carts, counters
Memory and performance trade-offs
Memcached's slab allocator excels when all values are similar size (e.g. 64 KB HTML chunks). Redis pays per-key overhead for metadata and type information — worthwhile when you need EXPIRE, HSET, or ZADD.
1M session tokens, ~200 bytes each:
Memcached: efficient slabs, no persistence overhead
Redis: hash per key + optional AOF — worth it for atomic TTL refresh
VaultCommerce benchmarks showed Redis at 98% of Memcached throughput for plain GET/SET on 1 KB values — the gap matters only above 500K ops/sec per node, where Memcached's threading wins for blob caching.
Migration signal
Move from Memcached to Redis when you need any of:
migration_triggers:
- atomic_counters_or_rate_limits
- complex_structures_without_serialization_roundtrips
- pubsub_for_cache_invalidation
- persistence_for_sessions_during_restart
- cluster_failover_with_sentinel
VaultCommerce migrated sessions after losing carts during a Memcached rolling restart — Redis persistence and replication justified the switch.
Quick recall
Everything you need if you only revisit this box.
- Memcached: simple, multi-threaded blob cache — best for uniform, opaque values.
- Redis: rich types, atomic ops, persistence, replication, and clustering.
- VaultCommerce: Memcached for HTML fragments, Redis for sessions, carts, and counters.
- Redis plain GET/SET is nearly as fast; choose on features, not micro-benchmarks alone.
- Migrate to Redis when you need atomicity, structures, or HA beyond client-side hashing.
Test yourself
Answer these before moving on — recall is what makes it stick.