Design a Feature-Flag Evaluation System

Implement a system that receives a feature flag and a user and decides whether that feature is enabled for that user. The source does not specify a rule language, rollout policy, or precedence order. Explain how you would define the evaluation contract, represent the configuration, and produce a consistent decision without inventing hidden business rules. ### Constraints & Assumptions - The result is an enabled/disabled decision for a particular flag and user context. - Clarify defaults, user identity, rule precedence, and missing attributes. - Treat percentage rollout and targeting groups as optional extensions to the agreed rule model. ### Clarifying Questions to Ask - Which targeting rules must be supported, and how are conflicting rules resolved? - What is the default when a flag or user attribute is missing? - Should a user receive the same decision across sessions and application instances? ```hint The evaluator needs a versioned, complete configuration snapshot. Reading half of one configuration version and half of another can produce a decision neither version intended. ``` ### What a Strong Answer Covers Describe configuration validation, deterministic evaluation, explicit precedence and defaults, and a safe update path. Explain what decision evidence can be recorded without exposing sensitive user data, and distinguish a missing flag from an intentionally disabled one. ### Follow-up Questions - How would you make percentage rollout assignments stable for one user? - What happens if the configuration service is temporarily unavailable? - How would you explain why one user received a different result from another?