DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

In Case of Emergency, Do Not Break — Feature Flagging

Learn how to handle the situation if your feature flagging system goes down.

Heidi Waterhouse user avatar by
Heidi Waterhouse
·
Oct. 15, 18 · Tutorial
Like (1)
Save
Tweet
Share
5.38K Views

Join the DZone community and get the full member experience.

Join For Free

What happens to your application when your feature flagging system goes down? There are two possibilities: fail-safe or fail-broken.

The first possibility is that nothing happens. This is the fail-safe mode. No updates to flag states are made, but everything continues to operate the way it has all along. And when the feature flagging system comes back up, there are no changes from the user point of view. This kind of system works because the flag state is set and then maintained on the client side-the flag evaluations are already made.

For example, if you are doing A/B testing in a fail-safe feature flagging system and the system goes down, everyone getting the 'B' variant will continue to receive the 'B' variant. They have already been evaluated and sorted into that bucket, and their identifier is used to retrieve the 'B' variant from the application servers.

In a fail-broken system, it's a little more complicated. Fail-broken systems are often more tightly-coupled and have the weaknesses of their strengths. When the client calls back to the flag evaluation on the unresponsive system, the call can fail, timeout, or return an error message. If it fails, the user may not see the feature controlled by a flag. If it times out, the user may experience it as general slowness. If there's an error, it may get passed through to the user.

In an A/B test that is running in a fail-broken environment, users who should get the B variant may get an empty element or an error message. The application page would need to be designed to catch errors from the flagging system and smooth them out for the users.

There are reasons to use a system that fails broken. You may need indications that it's broken, or it may be dangerous to assume that you can continue to serve the same state without checking back in with the application. For most applications, however, it's better to fail safe than to present users with errors.

Thinking about failure states is a type of testing and an essential part of making sure your application will behave in the way you expect it to, even in the face of unknown-unknown failure states.

application

Published at DZone with permission of Heidi Waterhouse, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Last Chance To Take the DZone 2023 DevOps Survey and Win $250! [Closes on 1/25 at 8 AM]
  • Exploring the Benefits of Cloud Computing: From IaaS, PaaS, SaaS to Google Cloud, AWS, and Microsoft
  • A Beginner's Guide to Back-End Development
  • Debugging Threads and Asynchronous Code

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: