fork download
copy 
  1. /* package whatever; // don't place package name! */
  2.  
  3. import java.util.*;
  4. import java.lang.*;
  5. import java.io.*;
  6.  
  7. /* Name of the class has to be "Main" only if the class is public. */
  8. class Ideone
  9. {
  10. 	public static void main (String[] args) throws java.lang.Exception
  11. 	{
  12. 		// your code goes here
  13. 		/* 
  14. 		# 1. Problem Statement
  15.  
  16. Build an in-process Feature Flag Service that an application can embed and query at runtime. The service decides, for a given flag and a given evaluation context (user, tenant, request attributes), what value to return.
  17.  
  18. ### 1.1. Core Functional Requirements
  19.  
  20. 1. Flag types: boolean, string, integer. Flags have a name, a default value, and a value type.
  21. 2. Targeting rules: a flag's evaluation can return different values based on attributes of the evaluation context (e.g., `country == "IN"` → `true`, otherwise `false`).
  22. 3. Percentage rollouts: a flag can be rolled out to N% of users. Same user must consistently get the same answer across calls (sticky bucketing). Same user must also get the same bucket *across different flags' rollouts* of the same percentage scheme only if the flag is configured to share the bucketing key - otherwise buckets must be independent. (Resolve ambiguity in your plan.)
  23. 4. Environments: flags are defined per environment (e.g., `dev`, `staging`, `prod`). The same flag can have different configurations across environments.
  24. 5. Live updates: flag configuration must be updatable at runtime without a service restart. Update propagation latency budget: under 5 seconds.
  25. 6. Evaluation API: synchronous, low-latency. Must never throw to the caller; on internal error, return the flag's default value and emit a structured error log.
  26. 7. Configuration source: assume an in-memory config store with a method `set(flag_config)` and `get(flag_name, env)`. You decide how the SDK consumes it.
  27. 8. Tests: unit tests covering flag types, targeting rules, percentage stickiness, environment isolation, default-on-error.
  28.  
  29. ### 1.2. Required Behaviors You Must Resolve in Your Plan
  30.  
  31. These are deliberately ambiguous. Decide and justify in `PLAN.md`:
  32.  
  33. - What is the bucketing key for percentage rollouts? (User ID? Hash of user ID + flag name? Tenant + user?)
  34. - What happens when targeting rules and percentage rollout are both defined on the same flag? Which takes precedence?
  35. - What happens on misconfiguration (e.g., percentage > 100, type mismatch on rule value)? Reject at config time, fail-safe at evaluation time, or both?
  36. - How does the SDK consume config updates - pull (poll), push (subscribe), or both?
  37.  
  38. ### 1.3. Out of Scope
  39.  
  40. - A real persistent store (in-memory is fine).
  41. - A UI / admin panel.
  42. - Network/transport layer (treat config delivery as an in-process API).
  43. - Multi-region replication.
  44.  
  45. ---
  46.  
  47. ## 2. Process Requirements
  48.  
  49. - Write `PLAN.md` first. Walk the interviewer through it before invoking your agent for implementation.
  50. - Commit incrementally. The git log is part of the deliverable.
  51. - Tests are the unit of progress. No "done" without green tests.
  52. - The interviewer will introduce an extension around minute 70. Plan your time accordingly.
  53.  
  54. 		*/
  55. 	}
  56. }
Success #stdin #stdout 0.07s 52536KB
comments (?)
stdin
copy 
Standard input is empty
stdout
copy 
Standard output is empty
https://ideone.com/AgCdQE
language:
Java (HotSpot 12)
created:
2 days ago
visibility:
public

Share or Embed source code

Discover > Sphere Engine API

The brand new service which powers Ideone!

Discover > IDE Widget

Widget for compiling and running the source code in a web browser!