🚩
Platform & Risk

Feature Flag Service

Low Latency Evaluation Aur Rollout
💡 Feature flag service EK SWITCH BOARD hai jo poore ghar ke liye hai. Sabse zaroori baat — switch dabane ke liye ghar ka main supply kabhi band nahi hona chahiye, aur switch board kharab ho jaaye to lights apne aap band nahi ho jaani chahiye.

Sabse important design constraint: flag evaluation NETWORK CALL nahi ho sakta. Har request par remote service call karna latency aur ek naya single point of failure add kar deta hai. Sahi design: SDK saare flag rules ko LOCALLY cache karta hai aur evaluation in-process hoti hai — microseconds mein.

Rules ko fresh rakhne ke liye SDK server se streaming connection (SSE/WebSocket) rakhta hai — flag badalte hi push ho jaata hai. Aur FAIL-SAFE hona chahiye: service down ho to SDK last known config use kare, aur wo bhi na ho to code mein diya gaya default. Percentage rollout ke liye consistent hashing use hoti hai taaki ek user hamesha same bucket mein rahe.

// Evaluation in-process — koi network call nahi
if (flags.isEnabled("new-checkout", user)) { ... }

// Percentage rollout — consistent hashing
bucket = hash(flagKey + userId) % 100
enabled = bucket < rolloutPercentage
// Same user hamesha same bucket => experience flicker nahi karta

// Fail-safe: streaming config → local cache → code default
🚩
Feature flag service EK SWITCH BOARD hai jo poore ghar ke liye hai. Sabse zaroori baat — switch dabane ke liye ghar ka main supply kabhi band nahi hona chahiye, aur switch board kharab ho jaaye to lights apne aap band nahi ho jaani chahiye.
1 / 2
⚡ Quick Recap
  • Evaluation local aur in-process — har request par network call kabhi nahi
  • Streaming updates se config fresh, local cache se speed
  • Consistent hashing (flagKey + userId) se stable percentage rollout
Is page mein (2 subtopics)

Flags sirf on/off nahi hote. Rules hote hain: specific users ke liye on, kisi segment (plan=enterprise) ke liye on, percentage rollout, aur baaki sabke liye default. Evaluation ORDER matter karta hai — specific rules pehle, phir percentage, phir default.

Ye poora rule set SDK ko bheja jaata hai, isliye evaluation local ho sakti hai. Rules chhote hote hain (kuch KB), isliye saare flags ek saath cache karna practical hai.

evaluate(flag, user):
  if user.id in flag.individualOverrides: return override
  for rule in flag.segmentRules:          // plan, country, version
      if rule.matches(user): return rule.value
  if inRolloutBucket(flag, user):  return true
  return flag.defaultValue

Feature flags ka bada use case A/B testing hai. Iske liye flag evaluation ke EVENTS collect karne padte hain — kaunse user ko kaunsa variant mila — aur unhe business metrics se join karna padta hai.

Ye events high-volume hote hain, isliye SDK unhe batch karke async bhejta hai. Evaluation kabhi network par depend nahi karti; event reporting best-effort hai aur uska fail hona flag ko affect nahi karta.

💡Tip: Flag cleanup ka zikr karo — purane flags technical debt hain. Har flag ki expiry date honi chahiye, warna kuch saal mein codebase hazaaron dead flags se bhar jaata hai.