Capstone: A Distributed E-Commerce Platform

In one line

Put it all together: an e-commerce platform where Redis provides the product cache, sessions, carts, atomic inventory holds, payment idempotency, gateway rate limiting, order event streams, notifications, product rankings, unique visitors, nearby warehouses, scheduled jobs, and cache protection, on replicated, persistent, monitored clusters, with PostgreSQL and Kafka as sources of truth.

0/7 · 0%

Think of it like this

Running a department store. Every technique you've learned is a department: the shop floor displays (cache), fitting rooms (sessions), baskets (carts), stockroom holds (inventory), the till (idempotent payments), the doors (rate limiting), announcements (notifications), and the manager's reports (analytics). The skill is making them work together, and knowing what happens when one closes.

Key ideas

01
Product API: cache-aside product documents with TTL + jitter, versioned keys, stale-while-revalidate for hot products, a Bloom filter for non-existent IDs, negative caching, L1 for launch products, Query Engine for listing filters (optional).
02
User and cart: sessions as hashes with sliding + absolute expiry and a device index; carts as hashes ({user:id}:cart), persisted to the database on checkout start and periodically.
03
Inventory: an atomic reservation script (check stock, decrement, record a hold with TTL), with the database as final arbiter at payment; holds expire and return stock via a scheduled sweeper.
04
Payments: idempotency keys (Redis fast path + database unique constraint + provider idempotency).
05
Gateway: token bucket per user and per IP, fail open with local fallback; stricter fail-closed limits on login.
06
Events and workers: outbox → Kafka for durable order events; Redis Streams for internal work queues (emails, invoice PDFs) with consumer groups and DLQs; Pub/Sub for real-time order status to WebSocket servers.
07
Rankings and analytics: sorted sets for best sellers per category per day; HyperLogLog for unique visitors; bitmaps for daily active users; minute-bucket counters for dashboards.
08
Location: GEO set of warehouses and pickup points for "available near you".
09
Scheduling: sorted-set delayed jobs for cart-abandonment emails and hold expiry.
10
Operations: separate clusters for cache (allkeys-lru, no persistence) and state (noeviction, AOF everysec), replicas across zones, ACL users per service, TLS, redis_exporter metrics with alerts, slowlog and latency monitoring, quarterly game days.

Code & diagrams

capstone.mermaiddiagram

Rendering diagram…

reserve.lualua

-- KEYS[1] = {sku:9}:stock, KEYS[2] = {sku:9}:holds (zset of orderId by expiry)
-- ARGV: orderId, qty, holdUntilMs
local stock = tonumber(redis.call('GET', KEYS[1]) or '0')
local qty = tonumber(ARGV[2])
if stock < qty then return 0 end
redis.call('DECRBY', KEYS[1], qty)
redis.call('ZADD', KEYS[2], ARGV[3], ARGV[1] .. ':' .. qty)
return 1
-- A sweeper returns expired holds: ZRANGE holds -inf now BYSCORE, INCRBY stock, ZREM.

Interview problem

The problem

Design the whole platform

Present the e-commerce platform's Redis architecture to a staff-level panel: product cache, sessions, carts, inventory, payments, gateway limits, order events, notifications, rankings, unique visitors, nearby warehouses, scheduled jobs, cache protection, HA, persistence and observability. For each, state the primitive, atomicity, failure behaviour and scaling.

You're given

10M daily users
Flash sales at 100× normal traffic
Payments must never double-charge
99.95% availability target

The interviewer follows up

During a flash sale, one SKU gets 200K purchase attempts per second. What changes?

Explain it without notes

For three components of the capstone, state the Redis primitive, atomicity mechanism and failure behaviour.

Practice

Build a slice of the capstone: product cache with stampede protection, cart hash, inventory reservation script and idempotent checkout, with a Kafka or Streams event on order creation.

Trade-offs

↔
Splitting cache and state clusters costs more infrastructure but isolates failures and eviction policies.
↔
Every Redis role adds speed and a failure mode; the design is only complete when each failure mode has a planned behaviour.

Done when you can

I can present a full Redis architecture with primitives, atomicity, failure behaviour and scaling for every component.
I can explain what Redis must never be the only source of truth for.

Command Palette