External configuration store pattern 

This pattern is applicable when configuration must be exported out of the application deployment package and into a centralized location. It is useful for sharing configuration data across applications and application instances.  

Changes to configuration should not result in administrative overhead, downtime, or redeployment. It is possible to edit these files to change the application behavior after the application is deployed. It might be challenging to manage configurations across multiple running instances of the application. It can result in instances using different configuration settings across multiple applications. These problems point to a dedicated configuration management system as a solution. 

The configuration management can be stored externally and provided an interface that can be used to quickly and efficiently read and update configuration settings. The type of external store depends on the hosting and runtime environment of the application.  It can be cloud-based storage or a dedicated configuration service or a hosted database or another custom system. 

There are a few things required from this store. First, the interface to read and update must be easy to use. The information must be properly organized. The implementation must authorize the user’s access for configuration protection. It should be flexible to allow storage of multiple versions of the configuration such as deployment, staging, or production. 

In addition, caching will be required for application performance. It depends on the type of backing store used, and the latency of this store. Caching minimizes the impact on application performance and provides fast access. External configuration stores might come with a local cache. 

The following issues and considerations must be tackled when implementing this pattern. 

A backing store must offer acceptable performance, high availability, robustness, and backups. Cloud storage or a configuration platform already come with this approach. The schema of the backing store must allow flexibility for types of information to hold. Multiple versions of settings and rollback are common task. 

The physical capabilities of the backing store also affect usability. If the store must store XML versus JSON, it will require parsing to read settings. Parsing increases the impact on performance. Control over the scope and inheritance of configuration settings will affect the delegation of control. Configuration interface must expose the configuration data in the required formats such as typed values, collections, key-value pairs, and property bags. 

A strict separation between the permissions to read and write configuration might be required and this will be implemented in the configuration store interface. Writing caching configuration data can help address transient connectivity issues. The application deployment pipeline must provide the last known set of configuration values and fallback to an earlier version if it cannot be used. 

Azure Table storage for key-values, Blob storage for hierarchical access, and cosmos DB are some examples for ISettingsStore. An ExternalConfigurationManager class can provide a wrapper over a BlobSettingsStore. This class might use Microsoft Reactive Extensions to publish changes made when the system is running.