#Feature Flags
Articles about Feature Flags — exploring patterns, best practices, and real-world implementations in production systems.
3 posts tagged with feature flags. ← Blog home
Scattered through most SaaS codebases is the same bug factory: `if plan == "pro"` checks guarding features. They work until the first pricing change, when "pro" splits into three plans, grandfathered customers keep old capabilities, sales grants an exception, and a trial needs temporary access — and suddenly product code is re-implementing billing logic badly. Entitlements are the missing layer: a dedicated system answering "may this customer do X?" so that product code never asks about plans at all.
Entitlements decouple what customers can do from what they pay: features (boolean, limit, quota), grants with sources and validity, and resolution behind one fast cached check — with plans demoted to versioned bundles. Pricing re-packages freely without product deploys, and exceptions become auditable.
Everything before this moment was preparation with an exit. Cutover is the moment traffic actually moves — reads, then writes, then trust — and its engineering question is blunt: how do you cross so that the first sign of trouble costs a flag-flip instead of an incident? The answer is incremental exposure, pre-staged rollback, and a disciplined patience about demolishing the bridge you just crossed.
Reads cut first (flags, percentage ramps through real peaks, cohort-sticky, canaried by the live mismatch rate); writes carry the asymmetry — reverse dual-writes keep rollback a flag-flip. Rollback is built and tested, the window declared — then the bridge is demolished on schedule, neither kept forever nor dropped early.
How you put new code into production is a design decision with real consequences for risk and downtime. Deploy it all at once and a bad release hits everyone; roll it out gradually and you can catch problems while they're small. Blue-green, canary, rolling, and feature flags are the core techniques — each trading complexity for safety in a different way. This post covers when and why to use each.
How you put new code into production is a design decision with real consequences for risk and downtime. Deploy it all at once and a bad release hits everyone; roll it out gradually and you catch problems while they're small. Blue-green, canary, rolling, and feature flags are the core techniques — each trading complexity for safety differently. When and why to use each.
All posts on this site are written by Pratik Dhanave, an Agentic AI Architect with 7+ years building production distributed systems, multi-agent AI platforms, and cloud-native infrastructure. About the author → Each article includes working code, architecture diagrams, and references to the specific frameworks and standards discussed. Browse the blog or explore related topics using the tag cloud above.