The Quest Begins (The “Why”)
Picture this: I’m huddled over my laptop at 2 a.m., eyes glazed, watching the metrics dashboard flash red like the Death Star’s super‑laser charging up. Our API is getting hammered by a burst of traffic from a misbehaving mobile client, and every request is punching straight through to the database. The DB starts to groan, latency spikes, and suddenly we’re serving 500s like they’re going out of style.
I’d tried slapping a simple per‑process counter on each server—just increment a variable in memory and reject when it crosses a threshold. It felt like trying to stop a horde of Stormtroopers with a cardboard shield. When we scaled out to three instances, each node had its own limit, so the effective ceiling tripled, and we still got slammed. Worse, when a node restarted, the counter reset and we opened the floodgate again.
I needed a solution that felt like wielding the Force: one unified view of traffic that works no matter how many instances we spin up, survives restarts, and doesn’t require a PhD in distributed systems to understand. That’s when I remembered the token bucket algorithm—an old school trick that, when paired with Redis, becomes a lightsaber for rate limiting.
