Figma's Next-Generation Data Caching Platform | Figma Blog

Figma built FigCache to address scalability, reliability, and operational weaknesses in its Redis-based caching infrastructure. The stateless proxy provides a unified Redis data plane, decouples Redis connections from volatile client fleets, centralizes routing and security, and standardizes observability. After rollout to Figma’s main API in 2025, the caching layer reached six nines of uptime.

Growing pains in caching

• Redis evolved from a secondary component into a critical dependency for site availability.
• Redis clusters were nearing connection limits as Figma’s infrastructure grew.
• Rapid client-service scaling caused thundering herds of new connections, creating I/O bottlenecks and reducing availability.
• Decentralized traffic management allowed applications to pollute or corrupt data across clusters.
• Client libraries provided inconsistent observability, complicating incident diagnosis and mitigation.
• A fragmented client ecosystem made it difficult to guarantee correct client-side behavior during failovers and topology changes.
• Figma initially reduced Redis dependency in core API subsystems and created service-specific connection pooling, but pursued a broader platform redesign for long-term scalability.

Design goals for a durable platform

Figma defined several objectives for a caching platform capable of supporting future growth:

• Decouple Redis from client volatility: Redis connection volume should not rise directly with elastic application fleets.
• Provide built-in observability: Service owners and platform operators should receive consistent, granular visibility across workloads in a multitenant environment.
• Hide Redis Cluster complexity: Clients should not need to manage topology changes such as scaling, failovers, or shard loss.
• Offer a universal endpoint: Applications should access multiple Redis clusters through a centralized routing layer rather than managing separate endpoints and clients.
• Enable alternative backends: New storage technologies, including durable systems, should be usable behind the same protocol and API.
• Remain extensible: Cross-cutting capabilities such as encryption, guardrails, and traffic backpressure should be implemented centrally rather than repeatedly in applications.

FigCache’s foundational architecture

• Figma identified the need for a caching proxy that would serve as:
  • A unified Redis data plane.
  • An ingress layer for applications.
  • A connection multiplexer shielding Redis from client connection spikes.
  • A language-agnostic interface that hides cluster routing and management.
• The platform was designed to centralize traffic decisions and abstract the underlying Redis topology from application developers.
• FigCache is stateless and communicates using the Redis RESP wire protocol, allowing existing Redis-compatible clients and first-party libraries to use it.
• Its broader platform role includes centralized security, routing, and end-to-end observability across the caching stack.

Results

• FigCache was rolled out to Figma’s main API service during the second half of 2025.
• The caching layer subsequently achieved six nines of uptime.
• The system established a foundation for more reliable, scalable, and interchangeable ephemeral storage across Figma.

Figma’s approach demonstrates that Redis reliability at large scale requires more than larger clusters: a dedicated platform layer can isolate connection volatility, simplify client behavior, and centralize operational controls.