We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A product team wanted to test a redesigned checkout flow with 100 beta users. The developer added an if statement checking a database flag. It worked, until a database migration reset the flag, enabling the unfinished checkout for all 50,000 users. Conversion rates dropped 30% in an hour because the new flow had incomplete payment integration.
Feature toggles go beyond simple on/off flags. They provide structured targeting: enable for specific user segments, percentages, environments, or even individual user IDs. They are evaluated at runtime without code changes or deployments.
The previous lesson covered feature flags (the concept of decoupling deployment from release). This lesson covers the targeting and evaluation mechanics: how toggles actually decide who sees what.
Toggle evaluation context:
| Context Attribute | Example Use |
|---|---|
| User ID | Enable for specific beta testers |
| User email domain | Enable for @company.com (internal dogfooding) |
| User plan | Enable premium features for paid users |
| Country | Enable for users in specific regions (regulatory compliance) |
| Percentage | Enable for 5% of all users (random, sticky) |
| Environment | Enable in staging but not production |
| Device type | Enable for mobile users only |
How evaluation works at scale. LaunchDarkly's SDK downloads all flag rules to the client application on startup (about 10-50 KB). Evaluations happen locally in microseconds, not over the network. The SDK streams updates via SSE (Server-Sent Events), so rule changes propagate to all application instances in under 200ms without polling.
Sticky assignment is critical for experiments. A user who sees variation A on their first visit must always see variation A, not randomly flip between variations. This is typically done by hashing the user ID with the flag name to produce a deterministic percentage bucket. hash(userId + flagName) % 100 gives a stable 0-99 bucket that never changes for the same user-flag pair.
When NOT to use toggles. For infrastructure-level changes like database migrations or schema changes that cannot be toggled at the application layer. Also avoid toggles for changes where partial rollout is meaningless (an API contract change that all consumers must adopt simultaneously).