Design Feature Flag System

Stripe's "Design Feature Flag System" interview question focuses on building a scalable service for dynamic feature control. It emphasizes low-latency evaluations across distributed environments, aligning with tags like System Design and A/B Testing.[1]

Problem Statement

Design a feature flag service that enables software teams to toggle features on/off at runtime without code deployments. The system must support targeted rollouts to specific user segments (e.g., by region, user ID, or percentage), handle 1M flag evaluations per second, and maintain minimal latency (<5ms p99).[3][1]

Functional Requirements

• Dynamic toggles for global on/off states.
• Targeting rules: user-based (ID, attributes), percentage-based rollouts, geographic regions.
• Client/server SDKs for fetching/evaluating flags via API.
• Real-time updates propagating instantly or near-instantly.
• Audit logs tracking changes (who, what, when).
• A/B testing integration for experimentation.[5][1][3]

Non-Functional Requirements

• Scale: Millions of users/flags, 1M+ RPS (90% reads, 10% writes).
• Latency: <5ms for evaluations; eventual consistency acceptable.
• Availability: High uptime with caching for resilience.
• No explicit input/output examples provided in sources; evaluations typically return boolean (enabled/disabled) per context (user/session).[1][3]

Constraints

• Read-heavy workload favors caching (e.g., Redis).
• Handle high write throughput for config changes without blocking reads.
• Ensure consistency across distributed clients/servers; no strong consistency needed for flags.
• Support web/mobile/server-side use cases without redeploys.[3][5]