Skip to content

SYSTEM Cited by 1 source

ResPC

ResPC (portmanteau of RESP — Redis Serialization Protocol — and RPC) is Figma's in-house Go library providing an RPC framework for building servers that speak Redis's native wire protocol. ResPC is the entry point to FigCache's core command processing and execution engine: it turns a stream of raw RESP bytes from Redis clients into structured, semantically-rich commands the proxy's backend can route and manipulate.

Why it exists

OSS Redis proxies shipped "rudimentary RPC servers that were not capable of extracting full, annotated arguments from arbitrary inbound Redis commands." Without structured arguments, a proxy can only pass commands through opaquely — no generic command-semantics- aware guardrails, no inline inspection, no custom command interception. ResPC is Figma's answer: a schema-driven RESP parser that exposes every command as a typed, annotated structure, and a pluggable command-dispatch layer for executing them.

Architecture

ResPC is split into four independent components:

  • Server layer. Accepts client connections, manages in-memory client-connection state, handles efficient network I/O.
  • Streaming RESP protocol parser. Handles incremental parsing + serialization of RESP messages over the wire — client's command bytes don't need to be buffered in full before processing can begin.
  • Schema-driven structured command parser. Derives semantically meaningful parameters from RESP commands, driven by a schema registry that declaratively expresses supported command sequences with annotated arguments. This is the load-bearing piece: structured args unlock everything downstream (routing by key, by command, by prefix; command-specific guardrails; inline mutation; fanout decomposition).
  • Command dispatch layer. Implementation-agnostic command processing + execution. In FigCache, this is the layer that implements the proxy's engine-tree logic — dispatching commands for execution against various upstream clusters.

Load-bearing properties

  • Structured input, structured output. Engine-tree nodes (in FigCache) consume structured ResPC commands and produce structured ResPC replies. Composable command pipelines over a wire protocol become tractable.
  • Streaming. Incremental parse + serialize keeps per-command latency low (no "wait for the full byte stream" stall).
  • Schema-registry-driven. New commands + argument shapes can be registered declaratively. The schema registry is how FigCache supports protocol extensions (custom commands — e.g. the language-agnostic multi-cluster distributed locking abstraction over Redlock, or the protocol-native graceful-connection-draining mechanism).
  • Implementation-agnostic dispatch. ResPC defines the RPC shape; callers decide how to execute — against real Redis, against a routing tree, against a static reply, etc.

Why it matters architecturally

ResPC is the primitive that lets FigCache be a drop-in RESP proxy while also doing command-semantics-aware things above the wire protocol — which the OSS-proxy landscape couldn't do. Generalizable: any wire protocol where a proxy needs to do more than opaque byte shoveling benefits from a ResPC-shape split (protocol parser → structured-command schema → dispatch).

Caveats / open questions

  • Go-only. No mention of other runtimes.
  • In-house / not open-sourced — no indication it's available outside Figma.
  • Schema-registry authoring model not detailed — how new command schemas are added, versioning, test harness.
  • Partial parse error handling not discussed — how malformed RESP / unknown commands surface to the dispatch layer.

Seen in

Last updated · 200 distilled / 1,178 read