System Design FAQ: Top Questions

A Feature Flag System allows teams to enable or disable features dynamically without redeploying code. It is critical for A/B testing, gradual rollouts, and risk mitigation.

📋 Functional Requirements

• Enable/disable features per user, group, or globally
• Support rules, percentage rollouts, and dynamic configs
• Provide real-time updates to services

📦 Non-Functional Requirements

• Low latency reads (100µs–1ms)
• High availability and caching
• Audit logs and versioning

🏗️ Core Components

• Flag Store: DB storing definitions (PostgreSQL, etcd)
• Evaluation SDK: Clients to evaluate flags in code
• Control Plane: Admin UI to define and update flags
• Delivery Layer: CDN or long-polling for config sync

🧪 Flag Schema (PostgreSQL)

CREATE TABLE feature_flags (
  flag_id UUID PRIMARY KEY,
  name TEXT,
  status BOOLEAN,
  rules JSONB,
  rollout_percentage INT,
  updated_at TIMESTAMP DEFAULT now()
);
        

🔧 Evaluation Code (Node.js)

function isFeatureEnabled(flag, userId) {
  if (flag.status === false) return false;

  // Apply percentage rollout
  const hash = hashFn(userId + flag.name);
  return (hash % 100) < flag.rollout_percentage;
}
        

🚀 Sync Methods

• Polling: Clients poll every 30 seconds for updated flags
• Push via CDN: Fast edge updates using Akamai/Cloudflare
• WebSocket Channel: Push flag updates to services in real-time

📈 Metrics & Logging

• Flag evaluation count per service
• Error rate and latency of flag fetches
• Flag change audit trail (who/what/when)

🔐 Security & Governance

• RBAC for who can change which flags
• Immutable versioning and rollback

🌐 Popular Tools

• LaunchDarkly, Unleash, Flagsmith, GrowthBook

📌 Final Insight

A feature flag system decouples deployment from release. It enables safer rollouts, quick reversals, and user-based experiments. Scalability comes from edge delivery, while correctness is ensured via atomic rules and robust SDKs.