Most engineers reach for Redis the moment someone says "we need a cache." It works, until data grows, traffic patterns shift, or you need something Redis wasn't designed for. Here are the trade-offs worth knowing before you spin up the instance. 🧵👇

4 questions worth answering before picking your cache: 1. How large will this data get? (memory ceiling) 2. Can I tolerate a cache miss? (fallback cost) 3. Do I need persistence across restarts? (durability) 4. Read-heavy or write-heavy? (throughput pattern)

"Design a rate limiter." This question shows up in 80% of big tech system design rounds. Most candidates jump straight to token bucket. That's not wrong but it's also not an answer. Here's how to actually structure a response that signals senior-level thinking. 🧵 @Redisinc

How to handle Redis going down: Option A: "Fail open" let all requests through (availability wins) Option B: "Fail closed" block all requests (safety wins) Option C: Local fallback counter with eventual sync (complexity wins)

I run load tests across 200+ services at Prime Video. Here's what breaks first during a gameday. It's never the service you tested last month. It's always the dependency nobody thought to check. 🧵

What happens after a game day matters more than the game day itself. Every finding gets triaged: severity, owner, fix timeline. But the real value is the institutional knowledge. Your team now knows how the system behaves under pressure before a live event.

Netflix made chaos engineering famous. Most engineers took one lesson from it: randomly kill servers and see what breaks. That's not chaos engineering. That's just breaking things. Here's what it actually is and why the difference matters at scale... 🧵👇

Where most chaos programs die: - They only test in staging (prod has different load patterns) - No defined steady state, so results are uninterpretable - Teams treat it as a one-time exercise, not a practice - Findings go into a doc nobody reads Process beats tools. Always.