Discusión: Recorrido de diseño de un servicio de feature flags: conjuntos de reglas, evaluación local y despliegues porcentuales estables

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

Traducción no disponible; se muestra el original. Original

'No subject flips back and forth during a rollout' is guaranteed by the stable hash only while the subject key is stable, and the subject key changes at the most important moment: a visitor is bucketed on an anonymous device or session id, logs in or signs up, and is bucketed again on the user id. With `flag_key + subject_key` hashing the two buckets are independent, so about half of the users in a 50 percent rollout see the variant switch at login, exactly where a checkout or onboarding experiment is measured. Serving pre-evaluated values to untrusted clients (step 5) makes it worse, because the server evaluates with whatever key the client had at request time. The fix is an explicit alias step in the SDK contract: when the identity changes, the client tells the service that anonymous key A is now user B, and the service either evaluates B with A's bucket for flags that were already evaluated (some commercial SDKs expose this as an `identify` or `alias` call) or the product accepts the flip and excludes such sessions from the analysis. The walk-through should name the rule, because the default behaviour is the silent flip.