Figma's FigCache: Six Nines Uptime via Custom Redis Proxy

Beyond Off-the-Shelf: Figma's Proxy-First Caching

Figma's proactive approach to building FigCache, their in-house Redis proxy, is a testament to the challenges of achieving extreme reliability (six nines uptime) in a distributed system. The decision to build a bespoke solution over adopting existing open-source proxies stems from the need for deep semantic awareness of Redis commands and the ability to implement custom guardrails and transparently handle a fragmented client landscape. This level of control is often necessary for hyper-scale applications where off-the-shelf solutions introduce limitations. The architecture, separating connection management and protocol parsing from backend execution, offers significant extensibility. The use of Starlark for runtime configuration of routing logic is particularly noteworthy, enabling dynamic adjustments without redeployments, which is a powerful paradigm for operational agility. The fanout filter engine, which transparently handles CROSSSLOT errors for multi-shard pipelines, is a clever abstraction that shields application developers from underlying complexity, directly contributing to improved availability and developer experience.

However, the significant investment in building and maintaining such a sophisticated in-house system represents a substantial operational overhead. While it delivers exceptional results, this path is only viable for organizations with the engineering resources and critical need for such precise control. The article highlights the complexity of supporting a fragmented client base and the decision to build shims for various Redis Cluster awareness and TLS configurations. This suggests that the initial development effort was considerable, and ongoing maintenance to keep pace with evolving client needs and upstream Redis changes will be a continuous challenge. The reliance on a custom RPC framework (ResPC) over RESP also introduces a proprietary component that, while effective, requires dedicated expertise. Furthermore, while the article mentions supporting alternative backends like MemoryDB and Postgres, the practicalities and performance implications of these integrations would be crucial for a holistic assessment of FigCache's long-term strategic value. The success of FigCache is intrinsically tied to Figma's specific technology stack and operational context, making direct generalization to other organizations challenging without understanding their unique constraints and priorities.

Key Points

• Figma developed an in-house Redis proxy, FigCache, to achieve six nines of uptime for its caching layer.
• This initiative addresses critical scalability and reliability issues, including connection saturation and fragmented observability.
• FigCache replaces a complex, fragmented caching stack, extending Figma's pattern of building proxy tiers to absorb operational complexity.
• The decision to build rather than buy was driven by the limitations of existing open-source proxies in semantic awareness and custom guardrail implementation.
• FigCache is built on ResPC, a Go library for RPC over RESP, and features a stateless architecture separating connection handling from backend execution.
• Runtime configuration via Starlark programs allows dynamic routing logic changes without server redeployments.
• A fanout filter engine transparently handles multi-shard Redis pipelines, resolving CROSSSLOT errors for applications.
• First-party client libraries wrap existing open-source clients, simplifying migration with reversible strategies.
• The project emphasizes unified observability, drastically reducing incident diagnosis time from hours/days to minutes.
• FigCache is designed for extensibility, potentially supporting alternative backends like AWS MemoryDB and Postgres.

---

📖 Source: Figma Builds In-House Redis Proxy to Hit Six Nines Uptime