Skip to content

SYSTEM Cited by 1 source

Service-Protection Framework (SPF, Pinterest)

SPF is Pinterest's in-house Service-Protection Framework — an in-process library integrated into application services that provides rate limiting plus "general throttling and concurrency control". SPF is the data-plane enforcement piece of Piqama's rate-limit variant: the Piqama control plane authors declarative rate-limit rules, those rules are distributed via PinConf, and SPF running inside the application process makes the actual request-time rate-limit decision locally.

Design intent

From the Piqama post: "Rate limit decisions should be made locally in the data path for scalability and performance reasons, with quota management happening in an async fashion. … Currently this is done by integrating an in-house rate limiting library into the application service. This enables fast rate limiting decisions (in contrast to relying on a global rate limiting service), and also the flexibility to make local decisions based on service health information (e.g. to support graceful rejection based on service capacity)." (Source: sources/2026-02-24-pinterest-piqama-pinterest-quota-management-ecosystem)

Two non-obvious design consequences:

  1. No hot-path round-trip to a global service. The rate-limit decision is in-process; all the hot-path needs is the already- distributed rule set (via PinConf) plus local counters.
  2. Local service-health is a first-class input. Because the decision is local, SPF can mix rule-based rate-limiting with local-health signals (saturation, current latency percentile) to produce a graceful rejection under overload — not available to a global-rate-limit-service design where health lives on the host and the decision lives on the service.

Canonical wiki instance of the local rate-limit decision architectural choice and the async-centralized quota + local enforcement pattern.

Role in the Piqama rate-limit integration

  • TiDB — initial Piqama rate-limit integration via SPF.
  • Key-Value Stores — initial Piqama rate-limit integration via SPF.
  • Future: more storage services, LLM Serving, etc.

Seen in

Caveats

Stub page — the Piqama post says "We'll defer the details of SPF in a future blog post". The underlying rate-limit algorithm (token bucket / sliding window / concurrency-based / adaptive), how local service-health is combined with rule-based limits, rule update semantics, per-host coordination (if any), and per-service failure modes are all deferred.

Last updated · 319 distilled / 1,201 read