Skip to content

CONCEPT Cited by 1 source

Pluggable validation framework

A pluggable validation framework is a control-plane contract: applications register custom validation hooks that run at the relevant lifecycle events (create, update, delete), covering both schema-level (structural) and semantic-level (invariant) constraints — and including hooks to remote services for checks that depend on live state the control plane doesn't own.

Three levels of validation

  1. Schema validation — the input matches a well-formed shape (field types, enumerations, required fields, ranges). Usually handled by a schema system (JSON Schema, Protobuf, Avro).
  2. Semantic validation — cross-field invariants inside the single update (e.g. max >= guaranteed). Requires custom logic because it depends on the meaning of the fields.
  3. Live-state validation — invariants that require looking up data outside the control plane's own store (e.g. "the sum of all project quotas on this cluster cannot exceed the cluster's physical resources"). Requires a remote-service hook — a callback to an external service that holds the authoritative state.

Most platforms get the first two; the third is the one that commonly gets dropped because it's awkward — and it's the one that catches the most damaging operator mistakes.

Piqama's named example

Pinterest's Piqama explicitly names the third level:

"The platform provides a pluggable validation framework. Users can define custom validation rules for both schema and semantic levels, and even integrate with remote services for advanced validation (e.g., ensuring the sum of all quotas does not exceed cluster resource capacity)." (Source: sources/2026-02-24-pinterest-piqama-pinterest-quota-management-ecosystem)

The cluster-capacity sum-check is the canonical remote-service case: to check it, the validation hook must (a) query the current cluster capacity (via a cluster-manager API), (b) sum the currently allocated quotas (Piqama's own store), (c) confirm the proposed new value keeps the sum inside capacity.

Why "pluggable" rather than "built-in"

A generic quota platform like Piqama can't bake in every application domain's invariants. Pinterest's big-data quotas have their own invariants; TiDB rate limits have theirs; LLM serving will have different ones again. Making validation pluggable lets each domain inject its own rules without forking the platform. Same argument applies to dispatch and enforcement — see the broader generic quota management platform pattern.

Design considerations for remote-service hooks

  • Synchronous vs asynchronous. Synchronous gives strong invariants but adds latency to control-plane writes and a dependency on the remote service being up.
  • Fail-open vs fail-closed. If the remote check times out, does the update go through (fail-open, risks invariant violation) or reject (fail-closed, adds unavailability)?
  • Caching. Cached results speed the check but risk stale-state violations.
  • Authoritative vs advisory. Some checks can be downgraded to warnings; others must block.

(The Piqama post names the pattern but does not disclose which trade-offs it made on the cluster-capacity check.)

Seen in

Last updated · 319 distilled / 1,201 read