Skip to content

PATTERN Cited by 1 source

Config distribution for quota rules

Pattern: treat quota rules as a dynamic configuration payload and distribute them via the organisation's existing configuration- distribution substrate (feature flags, dynamic service config, etc.) — rather than building a bespoke rule-distribution tier for the quota system.

Why this is the right move

Most engineering organisations already have a robust config distribution system — used for feature flags, kill switches, and runtime service configuration. That system already has:

  • Push / pull delivery at fleet scale.
  • Rollout / rollback controls.
  • Access control + audit trail.
  • Staleness + freshness monitoring.
  • Integration with service-deploy tooling.
  • Client libraries with consistent semantics.

Quota rules share all these needs. Inventing a parallel pub/sub tier just for quotas duplicates that work and creates a second operational surface nobody wants.

Pinterest's implementation

Piqama authors and owns quota rules (authorization, validation, audit, rightsizing); rule delivery to subscribing hosts rides PinConf:

"We leverage Pinterest's config management platform (Pinconf) to deliver rate limiting rules on the subscribing hosts. This allows us to scale with Pinterest's config delivery infrastructure, similar to how we manage feature flags and other types of dynamic service configurations." (Source: sources/2026-02-24-pinterest-piqama-pinterest-quota-management-ecosystem)

The separation is clean:

  • Piqama → authoring, lifecycle, ownership, validation, chargeback, rightsizing.
  • PinConf → distribution.
  • SPF (in-process library) → local enforcement at request time.

Generalises to other quota types

The Piqama architecture explicitly supports other dispatch mechanisms: "Piqama clients facilitate receiving the latest quota updates, the system is flexible, allowing users to utilize other dispatching mechanisms like Pinterest's config distribution system (PinConf) or their own custom dispatchers." For capacity quotas on Moka, Piqama uses its own client (polled by the Yunikorn Config Updater). For rate-limit rules, PinConf. The pattern applies wherever a config-distribution tier already exists.

Design properties

  • Async, eventually consistent. Rule updates take effect when the config tier's push/pull cycle completes — typically tens of seconds. Acceptable for rate-limit / capacity quotas where brief inconsistency window doesn't violate correctness.
  • Decouples enforcement availability from authoring availability. The enforcing host caches the last-pushed rule set; Piqama can be down and enforcement still works on the last-known-good config.
  • Low engineering cost. New services can integrate with quota rules using the same client they already use for feature flags.

Trade-offs

  • Config tier becomes a shared dependency. PinConf downtime affects not just features but also rate-limit rollouts.
  • Rule rollout rate limited by config tier fanout. If PinConf pushes config updates every N seconds, quota rule updates inherit that cadence.
  • Need to budget config payload size. Large rule sets bloat the config payload. Pinterest's post doesn't disclose how big Piqama's rule fleet is.

Applies beyond rate limits

Any system where the host-local component needs a declarative rule set that updates asynchronously can ride this pattern:

  • Rate-limit rules (Piqama).
  • Routing rules (proxy / gateway configs).
  • Allow / deny lists.
  • Experiment-configuration / traffic-shaping.
  • Admission-control policies.
  • Pricing rules (where brief inconsistency is tolerable).

Seen in

Last updated · 319 distilled / 1,201 read