Deterministic assignment is a method of assigning users to experiment variants by hashing a stable identifier (typically the user ID) combined with a salt, so that the same user always maps to the same variant without storing any state. The assignment is computed, not looked up.
This approach eliminates the need for a central assignment database. Every flag evaluation can be resolved locally, in microseconds, with no network call. It's the mechanism behind sticky assignments in most modern experimentation platforms, including Confidence.
How does deterministic assignment work?
The core operation is a hash function. You take a user identifier (user ID, device ID, or anonymous session ID), concatenate it with a salt that's unique to the flag or experiment, and run the result through a hash function like MD5, SHA-256, or MurmurHash. The hash output is mapped to a number in a fixed range (say 0 to 999), which determines the user's bucket. The bucket determines the variant.
Because hash functions are deterministic by definition, the same inputs always produce the same output. No state to persist. No database to query. No race conditions between distributed servers.
At Spotify, this mechanism is called the salt-machine algorithm, described in their engineering blog post on the new experimentation platform. Each experiment gets its own salt, so a user's assignment in one experiment is independent of their assignment in another. Changing the salt reshuffles all assignments, which is useful when you need to reset an experiment.
Why not just store assignments in a database?
The stateful alternative (write each assignment to a database, read it back on every evaluation) works, but it introduces three problems.
Latency. Every flag evaluation requires a network round-trip. For server-side flags evaluated on every API request, this adds milliseconds per request. For client-side flags that need to resolve before rendering UI, the delay is visible.
Availability coupling. If the assignment database goes down, flag evaluations fail. Your feature flag system becomes a single point of failure for your entire application. Confidence's local evaluation mode avoids this: flags resolve in-process, so a Confidence outage doesn't affect your flag evaluations.
Scale. At Spotify's scale (750 million users, 10,000+ experiments per year), an assignment database would need to handle billions of rows and millions of reads per second. Deterministic hashing replaces all of that with a computation that takes microseconds.
What are the limitations?
Deterministic assignment assumes a stable identifier. For logged-in users, the user ID works. For anonymous users, you need a device-level or session-level identifier, and stickiness lasts only as long as that identifier persists (it breaks when the user clears cookies or switches devices before logging in).
The other constraint is that assignments are coupled to the hash function and bucket allocation. If you want to change the traffic split (say, from 50/50 to 80/20), the specific users assigned to each variant will shift. Confidence handles this through careful bucket range management: expanding a rollout from 5% to 20% adds buckets 50-199 to the treatment group while keeping buckets 0-49 unchanged, so existing treatment users aren't reassigned.