<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Performance on Rohit Garg</title><link>https://rohit-garg.me/tags/performance/</link><description>Recent content in Performance on Rohit Garg</description><generator>Hugo</generator><language>en</language><copyright>© Rohit Garg</copyright><lastBuildDate>Wed, 27 May 2026 10:00:00 +0530</lastBuildDate><atom:link href="https://rohit-garg.me/tags/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>Redis Big Key Outage Took Down a Microservice System</title><link>https://rohit-garg.me/redis-big-key-outage/</link><pubDate>Wed, 27 May 2026 10:00:00 +0530</pubDate><guid>https://rohit-garg.me/redis-big-key-outage/</guid><description>&lt;p>A Redis outage is not always caused by Redis being down.&lt;/p>
&lt;p>Sometimes Redis is alive, accepting connections, and returning results. The problem is that one request path has quietly become expensive enough to slow everything behind it. In a microservice architecture, a Redis big key can spread latency through worker pools, connection pools, retry loops, and database fallbacks until the symptom looks nothing like the cause.&lt;/p></description></item></channel></rss>