Partition keys
A partition key answers a simple question: whose recent activity should this request be compared with?
Client A and client B
Suppose POST /orders has a client extractor that reads X-Client-ID. A partition named by_client uses that extracted value. If Client A sends eight requests and Client B sends two, their counts stay separate:
| Request | Partition used | Recent history updated |
|---|---|---|
X-Client-ID: A | by_client for A | Only A's /orders history |
X-Client-ID: B | by_client for B | Only B's /orders history |
That lets a feature like “requests by this client in the last minute” describe the right actor. It does not mean A and B get different models: the endpoint's selected model still scores both feature vectors.
How to define one
A partition has a name and one or more ordered extractor components. One component is simple; several make a composite key. For example, ["client", "region"] separates the same client across regions. Order and scalar type matter, so string "42" and number 42 are not the same input.
Choose a stable field that represents the actor you care about. A caller-controlled identifier can be spoofed unless your proxy or application validates it. PragmaChange uses Nginx's resolved client address for a client-IP extractor, not an untrusted forwarded-address header.
Why the displayed key is a hash
The runtime combines the pipeline version, partition name, and typed component values, then derives a key with HMAC-SHA256 and a locally supplied 32-byte secret. Raw client values are not stored as visible partition keys. The returned key includes a public pipeline-version prefix so quotas remain separate by version.
The secret lives on the Nginx host and is not included in release exports. Keep it private and consistent across reloads. Rotating it creates new keys, so existing partition histories no longer match and warm-up starts again.
Warm-up and bounded memory
The runtime needs to observe a partition for the longest window used by its features before it can produce a complete vector. A quiet interval still counts as observed time; history before the first request is never invented. Until warm-up completes, the result is check with no score.
Each pipeline has a maximum partition count. The shared-memory zone and per-partition history also have limits. Old partitions may be evicted when capacity is tight; an evicted partition starts warm-up again on its next request. If too many events force truncation, that history is marked incomplete and warms up again. A state serialization that exceeds its limit yields check with a capacity reason.
Scope in v1
New pipelines use one endpoint, and partition histories are separate within it. Recent state is shared by workers in one Nginx instance, but not across different hosts. A multi-proxy deployment therefore has independent windows on each proxy.
For exact encoding, timing, and quota rules, see the product repository's docs/runtime.md after the source is published.
The optional behavior service maintains its own application histories. Its workflow identities and pseudonymization do not turn native Nginx windows into cross-host state.