Design a Global Feature Flagging and Dynamic Configuration Platform
You are tasked with designing a global feature flagging and dynamic configuration service similar to LaunchDarkly or Optimizely. Engineering teams across your organization will rely on this system for real-time feature rollouts, instant kill-switch operations, and rule-based user targeting.
Your design must address the strict decoupling of rule administration (Control Plane) from high-throughput flag evaluation (Data Plane). Applications will evaluate flags millions of times per second, and changes made in the dashboard must propagate globally within seconds without causing elevated latencies or cascading failures if the control plane goes down.
- Allow engineers to define boolean flags, multivariate flags, and complex attribute-based targeting rules.
- Propagate rule changes globally from the management UI to SDKs within 2 seconds.
- Evaluate flag rules for incoming users based on user context attributes (e.g., userId, country, plan, appVersion).
- Collect evaluation telemetry and impression events asynchronously for audit logging and rollout analytics.
- Evaluation Latency: Sub-5ms for server SDKs (in-process/local evaluation) and sub-50ms for client devices.
- Availability: 99.999% uptime for flag evaluation data path; 99.9% for management control plane.
- Partition Tolerance: Local SDKs and edge relays must serve cached rules during network disconnections.
- Scalability: Support up to 10 billion flag evaluations per minute globally.
100 million active client/server SDK instances globally. 10 billion total flag evaluations per minute. Control plane activity: 1,000 flag updates per day created by 500 internal engineers. Telemetry pipeline: 100,000 batched impression events/sec sent back to analytics storage.
- High-level architecture showing Control Plane (Admin/Rules Engine), Relay/Edge Distribution Layer, and SDK Execution Models.
- Data model for feature flags, targeting rules, and dynamic user segments.
- Detailed rule propagation mechanism (e.g., SSE/WebSockets streaming, CDN edge delivery, local memory caching).
- Telemetry and impression tracking architecture designed to prevent evaluation path blocking.
Strong designs explicitly isolate the management UI and rule storage (Control Plane) from the flag evaluation path (Data Plane). The diagram should clearly show local SDK in-memory rule evaluation or edge-relay evaluation, ensuring that zero evaluation traffic hits the primary database.
Evaluates how updates travel from the admin DB to millions of SDKs. A strong candidate details a pub/sub event bus streaming updates over Server-Sent Events (SSE) or WebSockets to edge proxies/relay daemons, combined with CDN fallback or persistent cache file backup for cold starts.
Assesses the trade-off between local rule evaluation (pushing compiled rule sets to SDKs) vs server-side evaluation (calling an API). Strong answers show how rule sets are compiled into optimized ASTs/JSON blobs pushed to SDKs for zero-network local evaluation.
Checks the decoupled handling of impression events. The design should show client-side/SDK batching, non-blocking asynchronous transmission, and a streaming ingestion queue (e.g., Kafka) feeding downstream analytics without impacting evaluation latency.
Verifies that the system handles network splits, control plane downtime, and SDK restarts. Strong solutions feature persistent local disk/memory storage for rule sets, default fallback values defined in code, and exponential backoff retry strategies.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Follow-up: How would your design handle real-time dynamic segment updates (e.g., 'evaluate TRUE if the user joined a beta cohort in the last 10 seconds') without turning every in-memory local SDK evaluation into a blocking remote database call?
Flag evaluations must take < 5ms for server-side SDKs and < 50ms for mobile clients. Flag rule updates published in the admin console must propagate globally to all connected instances within 2 seconds. The evaluation data plane must remain 99.999% available even during total control plane outages.
- Views
- 9