Figma builds FigCache, hits six nines

Caching sounds like backend plumbing, but at Figma it had become a product problem. Redis was no longer some optional speed layer — it sat on the critical path for keeping the app responsive and available. As Figma grew, that layer got messy enough that launches and incidents kept running into the same wall. So Figma built FigCache, a Redis proxy that now sits between services and Redis itself, and says the rollout has pushed its caching layer to six nines of uptime. (figma.com) ### What was actually broken? The problem was not “Redis is bad.” The problem was scale plus drift. Different services had accumulated different client libraries, different connection behavior, and different observability. That meant connection counts kept climbing toward hard limits, and fast service scale-ups could trigger a thundering herd of new conn(figma.com)nosis was slower because every client stack exposed a slightly different picture. (figma.com) ### Why not just patch each service? Figma tried that first. The team built local fixes, including a custom client-side connection pooling layer, and those fixes did help blunt outages. But they were basically shock absorbers, not a redesign. They reduced the blast radius without removing the structural reasons the blast kept happening. Once Redis had become a shared dependency for core product surfaces, that was not good enough. (figma.com) ### So what is FigCache? FigCache is a stateless proxy that speaks the Redis wire protocol. In plain English, app services talk to FigCache as if it were Redis, and FigCache handles the ugly parts in the middle — connection pooling, traffic routing, and a more consistent control point for security and observability. Figma also paired it with first-party (figma.com)er in their own code. (figma.com) ### Why build a proxy at all? A proxy lets one team absorb complexity once instead of making every product team absorb it badly. That is the real move here. If every service opens connections, handles failovers, interprets topology, and emits telemetry in its own way, the system gets more fragile with every new service. Put a smart layer in front, and yo(figma.com). It is the platform equivalent of replacing a pile of handwritten adapters with a real power strip. (figma.com) ### Why not use an open-source Redis proxy? Figma says the existing options were too limited for what it needed. The issue was not basic proxying — plenty of tools can forward commands. The issue was deeper semantic control. Figma wanted to inspect commands richly enough to add runtime guardrails and custom behavior, while also supporting a mixed client (figma.com)e team toward an in-house layer instead of maintaining a brittle fork. (infoq.com) ### Why does the six-nines claim matter? Because it turns an infrastructure story into a product reliability story. Six nines means 99.9999% uptime for the caching layer Figma is talking about, and the company says that milestone arrived after the main API rollout in the second half of 2025. The exact number is impressive, but the more important signal is that the redes(infoq.com)tening site availability. (figma.com) ### Is this part of a bigger pattern? Yes — and that may be the most interesting part. In 2024, Figma finished a separate rework of its Postgres layer using another proxy, DBProxy. FigCache extends the same idea into ephemeral data: when a storage layer becomes too central and too noisy to manage piecemeal, hide the complexity behind a purpose-built platform boundary. (figma.com) ### Bottom line? FigCache is not flashy infrastructure. But it shows how mature platform teams think. When a “shared service” starts causing repeated launch friction and availability pain, the answer is often not more local fixes. It is to make the shared layer boring, centralized, and enforceable — then let product teams stop thinking about it. (figma.com)