How ConfigCat SDKs Keep Applications Running During Outages
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.