Lajos Szoke

Outages happen. Even the best engineering teams and the most reliable infrastructure eventually run into network failures, service disruptions, or unexpected connectivity problems.

The real question is not whether a platform will ever experience an incident. It is what happens to your application when it does.

A feature flag service is often part of the path used to manage releases, disable problematic functionality, and respond to production issues. The last thing you want during an incident is for the feature flag system itself to make your application unavailable.

ConfigCat SDKs are designed to avoid that problem. They evaluate feature flags locally, keep using the latest valid configuration when refresh requests fail, and retrieve updates once connectivity returns. Your application does not need to be restarted or redeployed.

Let's look at how this fault-tolerance architecture works.

Local Evaluation: The Foundation of Fault Tolerance​

When you create feature flags and targeting rules in ConfigCat, they are distributed to SDKs through a static configuration file called config.json.

The ConfigCat SDK downloads and caches this configuration, then evaluates flags inside the application process. It does not contact ConfigCat every time your code checks a flag.

This distinction is important. Once the configuration has been downloaded, the SDK can evaluate flags locally using the cached targeting rules and rollout settings. Feature evaluations remain fast, and your application does not depend on a constant connection to ConfigCat for every decision it makes.

The network is only needed when the SDK checks for an updated configuration. If a refresh request fails, the SDK can continue evaluating flags using the version it already has.

This local evaluation model is a central part of the ConfigCat architecture and one of the reasons the SDKs can remain both fast and resilient.

At ConfigCat, we use the best feature flag provider in the world. Plot twist: it's ConfigCat. We're basically in a committed relationship with ourselves. Some call it narcissism; we call it quality control.

In this article, we'll share real-world feature flag examples from production, explain how we use our own system inside ConfigCat, and confess the biggest feature flag mistake we've ever made (so you don't have to repeat it).

Unless you’ve been living under a rock for the past two years, chances are you’re well-acquainted with today’s hybrid work environment and the tools that come with the territory. Platforms such as Jira, Trello and Slack are well established as tools that enable high-level remote collaboration and task management. ConfigCat provides straightforward integrations with Jira, Trello, and Slack that allow for higher visibility and easier, more convenient feature flag management. In this blog, I’ll go through these feature flag devices one by one, outlining their functionality and how to integrate them.

Manage your feature flags from Visual Studio Code using ConfigCat's new Visual Studio Code Extension.

ConfigCat's validation phase was a success in our eyes, so we had to step ahead. Above making a great product with great features we had to provide a really stable and reliable system.

In the next few articles I would like to introduce the core infrastructure of ConfigCat, how it has evolved over time and what challenges we faced through its validation phases.

Manage your feature flags from Jira Cloud using ConfigCat's new Jira Cloud Plugin.

Get updated via a Slack Channel message when someone changes a feature flag with ConfigCat Feature Flags in Slack App Directory.

ConfigCat is using ConfigCat as a feature flag and configuration management service. Here is how and why.​

In this post, I will show you how we implemented the animations where the cat follows the cursor with his eyes when entering username and hides them when entering password.