Session Storage and Leaderboard Patterns

Traditional web applications store session data in memory on the server. This works with a single server but breaks when you scale horizontally — if a user's subsequent request is routed to a different EC2 instance, that instance has no knowledge of the user's session and the user is logged out. Sticky sessions (session affinity in the load balancer) solve this partially but reduce the effectiveness of load balancing. The scalable solution is to move session state to a shared, low-latency store accessible by all instances — which is exactly what ElastiCache Redis provides.

Storing sessions in Redis gives you: sub-millisecond session reads across all application servers, built-in TTL for automatic session expiry, atomic session updates to prevent race conditions, and the ability to immediately invalidate a session by deleting the key. The application stores the session ID in a cookie; on each request it looks up the session ID in Redis to retrieve the session data. All application servers share the same Redis, so any server can handle any user's request.

A fixed TTL means the session expires N seconds after creation regardless of activity. A sliding TTL (extending expiry on each access) is more user-friendly — the session expires N seconds after the last access. In Redis, implement sliding TTL by calling EXPIRE (or EXPIREAT) on the session key on every successful session read to reset the expiry countdown. This ensures active users are never unexpectedly logged out, while inactive sessions expire automatically, freeing memory.

An e-commerce shopping cart is a natural fit for Redis. Each cart is stored as a Redis Hash where the field is the product SKU and the value is the quantity. Hash operations like HINCRBY and HDEL allow atomic updates without retrieving and rewriting the entire cart. Combined with a TTL (to expire abandoned carts after 24 hours), Redis provides a fast, persistent cart store without the overhead of a relational database for every add-to-cart event.

A real-time leaderboard is a classic Redis use case enabled by Sorted Sets (ZSETs). Every player entry has a score; the sorted set maintains members in ascending score order at all times. Leaderboard queries (top N players, player rank, players in a score range) are O(log n) or O(log n + m) — extremely fast even for millions of players. Redis sorted sets are the foundation of many gaming, fitness, and social ranking features without needing a complex database query or recalculating rank on every page view.

Two common leaderboard features beyond 'show top 10' are show a player's rank and show players near a given player. Both are trivial with Redis sorted sets. ZREVRANK returns the 0-indexed rank of a player in descending score order. To show 5 players above and below a player, get their rank, then use ZREVRANGE from rank-5 to rank+5. This gives a personalised leaderboard view in two Redis commands — no complex SQL window functions needed.

Rate limiting (restricting how many requests a client can make in a time window) is another high-value Redis use case. The sliding window algorithm uses a sorted set where each member is a request timestamp. On each request: remove members older than the window, count remaining members, reject if count exceeds limit, add new timestamp. This implements precise sliding window rate limiting with millisecond resolution — far more accurate than fixed-window counters and without database overhead.

Distributed locks coordinate exclusive access to a shared resource across multiple application servers. Redis's SET key value NX EX ttl command provides atomic lock acquisition — it sets the key only if it does not exist (NX = Not eXists) and sets a TTL to prevent deadlocks if the holder crashes. When the operation completes, the holder deletes the key. The Redlock algorithm (using multiple Redis nodes for quorum) provides a more robust distributed lock, though it adds complexity. For most use cases, a single Redis node lock is sufficient.

Both ElastiCache Redis and DynamoDB can store session data, but they have different trade-offs. ElastiCache Redis: microsecond latency, in-memory (volatile unless persistence enabled), simpler data model, requires VPC. DynamoDB: single-digit millisecond latency (DAX can match Redis), fully managed with no cluster to maintain, durable by default, accessible globally with Global Tables, serverless with on-demand capacity. For the SAA-C03 exam: if the question emphasises microsecond latency or complex in-memory operations, choose Redis. If it emphasises durability, serverless, or global scale, consider DynamoDB.

Redis has a built-in geospatial data type (GEO commands) that stores latitude/longitude coordinates and enables proximity queries. Using GEOADD, GEODIST, and GEORADIUS (now GEOSEARCH in Redis 6.2), you can find all locations within a given radius of a point in O(n + log n) time. Use cases: find nearby drivers (ride-sharing), find restaurants within 5 km, sort search results by distance. This avoids a separate geospatial database and keeps location queries at in-memory speeds.

A HyperLogLog is a probabilistic data structure that estimates the count of unique elements in a set using a fixed amount of memory (12 KB in Redis) regardless of how many unique items are added. It provides approximately 0.81% standard error. Use PFADD to add elements and PFCOUNT to get the estimate. This is perfect for counting unique daily active users, unique page views, or unique IP addresses when exact counts are not required and memory efficiency matters. Storing millions of unique user IDs as a Redis Set would consume GBs; HyperLogLog uses 12 KB.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Redis session storage enables stateless horizontal scaling by giving all instances access to shared session state with sub-millisecond latency, Redis sorted sets power real-time leaderboards with O(log n) rank queries, and specialized Redis data types (HyperLogLog for unique counts, GEO for proximity, distributed locks) solve common architectural problems efficiently. This completes the Caching with ElastiCache course — next we explore High Availability and Fault-Tolerant Architectures.