Redis

Prerequisite: Familiarity with the concepts introduced in Part 1 — Location Ingestion. Review it first if the terminology in this part is unfamiliar. Answer-first: Uber and Grab find the nearest available driver in under 100ms by dividing the Earth’s surface into hexagonal cells (H3 index at Resolution 8, each ~0.74 km²). Instead of calculating distance to every driver, they look up only the 7 cells nearest to the rider — reducing millions of comparisons to dozens. ...

Prerequisite: Familiarity with the concepts introduced in Part 4 — Sre Chaos Engineering. Review it first if the terminology in this part is unfamiliar. Answer-first: Scaling for billion-yen cashback campaigns requires pre-warmed Redis cluster caching, token-bucket rate limiting at the API gateway, and async queue-based payment processing to shave peak traffic spikes. Answer-first: The PayPay campaign architecture isolates high-throughput reward campaigns from core payment processing. By evaluating campaign eligibility out-of-band and writing reward points asynchronously using event queues, PayPay prevents promotional traffic spikes from impacting critical credit card processing pipelines. ...

API rate limiting defends backend services by restricting request volume. Security requires a layered defense: Web Application Firewalls (WAF) block edge-level volumetric spikes, API Gateways manage L7 credentials and quotas, and application middleware enforces fine-grained business limits. Client identification must rely on validated, secure IP parsing (using the PROXY protocol or rightmost X-Forwarded-For checks). Prerequisite: This is Part 11 of the System Design Masterclass. Previous parts built the core components — this part covers securing APIs and managing client traffic spikes at scale. ...

Prerequisite: Part 7 of the System Design Masterclass. Read Part 6: Distributed Locks first. What You’ll Learn Payload Reuse Vulnerability: How Stripe prevents malicious request payload tampering on existing keys using SHA-256 request body hashes in Redis. SetNX Lock Lifetime Math: Why setting a lock TTL without a auto-extension renewal thread leads to double-charge execution gaps. Response Record Memory Leak: The memory consumption strategy of caching full HTTP headers and response body data under high-throughput request rates. What Is an Idempotency Key? Key Concept: An Idempotency Key is a unique token — typically UUID v4 — generated by the client and attached as an Idempotency-Key HTTP header. The server uses this key to detect duplicate requests: if the key has been seen before, return the cached response from the first execution without re-executing the handler. ...

Prerequisite: Part 6 of the System Design Masterclass. Read Part 5: Kafka & Event-Driven first. Distributed Locks in Go — Redlock Math, etcd & Split-Brain Answer-first: Distributed locks enforce mutual exclusion across independent microservice instances. Redis Redlock achieves high-performance locking across quorum master nodes with Lua-script atomicity, while etcd provides linearizable Raft-backed leases with fencing tokens to guarantee absolute safety under network partitions. Key Takeaways: Redlock Validity Formula: Lock validity equals $\text{TTL} - \text{elapsed_time} - \text{clock_drift}$; if validity $\le 0$, release immediately. Fencing Tokens: Monotonically increasing fencing tokens (e.g. etcd revision numbers) block delayed GC-paused lockholders at storage layer boundaries. Raft vs Redis Quorum: Use etcd for high-correctness financial transactions and Redis Redlock for high-throughput rate limiting or worker job distribution. What You’ll Learn Redlock Clock Drift Math: Why unsynchronized system clocks (NTP drifts) allow two clients to acquire the same Redis lock, and how to verify with fencing tokens. Rsync Lock-Release Failures: The dangerous Lua script race condition when executing un-coordinated lock releases in Redis under network partitions. etcd Keep-Alive Overhead: How etcd’s HTTP/2 stream heartbeats impact cluster CPU utilization when holding thousands of concurrent locks. Why Do Race Conditions Occur in Distributed Systems? Key Concept: Race conditions occur across server processes when multiple servers independently read and then write shared state without coordination. A single-process mutex doesn’t help — you need a lock mechanism visible across all processes. ...

Implementing write-through and cache-aside patterns in Go using Redis Sentinel guarantees cache consistency and protects downstream SQL databases. Prerequisite: Part 3 of the System Design Masterclass. Read Part 2: Load Balancing L4/L7 first. What You’ll Learn XFetch Mathematical Constants: How to configure the scaling factor ($\beta$) in XFetch to balance background refresh CPU usage against cache miss rates. Redis Memory Allocation Overhead: How Redis’s internal jemalloc allocator causes memory fragmentation, and why LRU evictions don’t immediately free up RAM. Singleflight Leakage: The danger of singleflight lockups when backend queries hang indefinitely, and how to guard it using Go context timeouts. How Does Cache Stampede Happen? Key Concept: Cache Stampede (thundering herd) occurs when a popular cached key expires and multiple concurrent goroutines simultaneously detect a cache miss — then all query the database simultaneously. The burst of duplicate DB queries can exceed connection pool capacity and cause cascading failure. ...

Answer-first: Redis semantic caching for routing queries utilizes geo-hash indexing and embedding similarity vectors to serve frequent route lookups with sub-5ms latency. Prerequisite: Before reading this part, review Part 5: Route Visualization UI. Part 6: Location Clustering with Uber H3 & Redis Semantic Caching Answer-first: Semantic caching transforms continuous floating-point GPS coordinates into discrete Uber H3 hexagonal keys (Resolution 8/9), increasing cache hit rates from 0% to over 80%. Combining H3 spatial keys with Redis MGET pipelines and XFetch early recomputation prevents cache stampedes and lowers matrix latency to <2ms. ...

Answer-first: Spatial indexing serves as a high-performance pre-filtering layer that prevents heavy routing engines from collapsing under load. By using Uber H3 hexagonal cells and Redis GEO to narrow down 10,000 active drivers to the 50 closest candidates in RAM (<2ms), systems reduce routing engine CPU overhead by up to 95%. Prerequisite: Before reading this part, review Part 2: Zero to Hero Environment Setup. Part 3: Spatial Indexing — Uber H3, PostGIS & Redis GEO Answer-first: Spatial indexing serves as a high-performance pre-filtering layer that prevents heavy routing engines from collapsing under load. By using Uber H3 hexagonal cells and Redis GEO to narrow down 10,000 active drivers to the 50 closest candidates in RAM (<2ms), systems reduce routing engine CPU overhead by up to 95%. ...

Prerequisite: Read the previous article: Chapter 7: Fortifying Payment Systems with Idempotent APIs. In a standalone Go application, preventing two Goroutines from overwriting the same data (Race Condition) is achieved via sync.Mutex. However, when your system scales out to 10 servers behind a Load Balancer, sync.Mutex is useless because it only locks local RAM. You need a Distributed Lock. 1. Basic Redis Locks A basic Redis lock utilizes SET resource id NX PX ttl. It works for simple caching but suffers from Single Point of Failure vulnerabilities if the Redis Master crashes before syncing. ...

Prerequisite: Read the previous article: Chapter 6: API Gateway vs Service Mesh in Microservices Architecture. In E-commerce or Fintech, the ultimate nightmare is not a system crash, but charging a customer twice for a single order. This is usually caused by network lag, an impatient user double-clicking “Pay”, or automated app retry logic. The mandatory solution for any transactional API (Payment/Order) is Idempotency. 1. What is Idempotency? An operation is idempotent if executing it once or N times yields the exact same system state and outcome. While GET and PUT are natively idempotent, POST requires explicit engineering. ...

Prerequisite: Before reading this chapter, review Chapter 2: The 3 Caching Vulnerabilities. Chapter 3: Distributed Rate Limiting with Redis & GCRA Algorithm Answer-first: Distributed rate limiting in microservice architectures requires centralized state management in Redis to avoid load-balancer bypasses. Implementing the Generic Cell Rate Algorithm (GCRA) via atomic Lua scripts tracks Theoretical Arrival Times (TAT) using a single 64-bit integer per user key, guaranteeing sub-millisecond execution. Key Takeaways: Local Limiter Flaws: Local in-memory limiters fail under multi-node load balancers because traffic distribution allows clients to multiply effective throughput limits. GCRA Efficiency: GCRA tracks arrival time deltas rather than token counts, requiring only one Redis key lookup per request. Lua Atomicity: Executing GCRA calculations inside Redis Lua scripts eliminates race conditions between concurrent API Gateway nodes. What You’ll Learn GCRA TAT Mathematics: How Theoretical Arrival Time formulas ($TAT = \max(now, TAT) + \tau$) calculate exact retry delays. Lua Script Race Conditions: Why atomic execution in Redis single-threaded engine is mandatory for rate limit precision. Memory Footprint Math: Comparing GCRA (1 key/user) against Token Bucket and Sliding Window Log memory overheads. If caching is the shield protecting your database, Rate Limiting is the armor guarding your API servers from DDoS attacks and resource exhaustion caused by abusive clients. ...

Multi-tier distributed caching using Redis clusters and in-memory LRU buffers prevents database thundering herd and reduces read latency to sub-millisecond ranges. Prerequisite: Before reading this chapter, review Chapter 1: How Systems Handle Millions of Requests/s. What You’ll Learn Bloom Filter Math: How to calculate bit array sizes ($m$) and hash function counts ($k$) for <1% false positive rates. XFetch Beta Tuning: Adjusting the scaling factor ($\beta$) to force probabilistic background recomputation before TTL expiration. Singleflight Timeout Leaks: Guarding singleflight calls with Go context deadlines to prevent goroutine hangs. Caching is the ultimate shield for databases in distributed systems. However, poorly implemented caches can become the exact reason your system crashes. In this chapter, we dissect three classic caching phenomenons and how to defend against them using Golang. ...

Real-Time Inventory Topology: CDC, Kafka, and Redis Real-time inventory synchronization is the process of propagating stock count changes from the system of record (database) to all sales channels — web storefront, mobile app, WMS, ERP — in sub-second time. Instead of batch ETL jobs that run every hour, a CDC + Kafka pipeline streams every committed stock change as an event, eliminating overselling and stale stock displays. Handling this during a flash sale — where thousands of users attempt to purchase a highly contested SKU simultaneously — is a pinnacle architectural challenge. Traditional synchronous database updates collapse under lock contention. ...

Flash Sale Architecture: Rate Limiting & Redis [!NOTE] On sourcing: This article describes flash-sale architecture patterns for C10M-scale events; it is not a disclosure of Shopee’s internal systems, and the figures here are engineering targets rather than published Shopee metrics. Shopee has not publicly documented its flash-sale internals in detail. What is public is its database platform choice — Shopee’s adoption of TiDB is documented in PingCAP’s case studies (How Shopee Chose the Right Database, Shopping on Shopee, the TiDB Way). Treat everything else as a reference pattern to validate against your own workload. ...

Prerequisite: Familiarity with the concepts introduced in Part 6 — Rise Of Ai Agents. Review it first if the terminology in this part is unfamiliar. Part 7 — Agentic Memory Systems: Episodic, Semantic & Working Memory Storage To act as effective digital partners, enterprise autonomous agents must remember past user decisions, architectural preferences, and historical tool execution results across weeks or months of operation. Treating every interaction turn as a fresh stateless request leads to frustrating user experiences where the agent continuously re-asks foundational questions. ...

Surge Pricing Algorithm & Spatial Indexing Architecture Why is it that every time it rains, ride-hailing fares double, or even triple? It’s not a human operator manually adjusting the prices behind a desk. Rather, it’s the result of an incredibly sophisticated Stream Processing engine running in the background executing the surge pricing algorithm. This analysis breaks down the architecture of a real-time dynamic pricing system: indexing geographical rider demand and driver supply using Uber’s H3 hexagonal spatial grids, aggregating supply/demand ratios over Redis sliding windows, and calculating dynamic fare multipliers while damping oscillations and preventing boundary gaming. We also cover why Scaling your Database to handle Surge traffic is a strict prerequisite to prevent your system from crashing during massive traffic spikes. ...

Answer-first: Shopee prevents overselling during high-concurrency flash sales by combining local memory caching, Redis inventory sharding, and atomic Lua script decrements. This multi-tier architecture isolates hot keys in Redis memory shards and evaluates stock availability in sub-milliseconds without acquiring relational database locks. Chapter 2: Flash Sale Engine - The Mystery Behind Redis and Hot Keys ← Series hub | ← Prev | Next → Prerequisite: Read the previous article: Chapter 1: Microservices Foundation - The Power of Go, gRPC, and API Gateway. ...