External Configuration Store
External Configuration Store centralizes settings outside deployment packages so all instances share and refresh them at runtime. It enables consistent, auditable, redeploy-free config changes but makes the store a critical, security-sensitive dependency.
The External Configuration Store pattern keeps configuration settings outside the application deployment package, in a centralized store that all instances read at runtime. Configuration becomes a managed, shared resource rather than something baked into each build or local file.
The problem is that configuration embedded in deployment packages or local files is hard to change consistently across many instances, requires redeployment to update, and scatters settings (including secrets) across environments.
How It Works
Settings live in a dedicated store such as AWS AppConfig or Parameter Store, Azure App Configuration, HashiCorp Consul, or a key-value/secrets service. Applications read configuration from the store at startup and, ideally, refresh it at runtime so changes take effect without redeployment. The store typically supports environment-specific values, versioning, and access control, and integrates with a secrets manager for sensitive values.
A caching layer in each instance avoids hammering the store, with a refresh interval or change-notification mechanism to pick up updates. Centralization means one change propagates to all instances.
When to Use It
Use it when many instances or services must share consistent configuration, when settings need to change at runtime (feature toggles, connection strings, limits), and when configuration and secrets should be centrally governed and audited.
Avoid it for trivial single-instance apps where local config suffices, and never store unencrypted secrets in a plain config file when a secrets manager is available.
Trade-offs
The store becomes a critical dependency: if it is unavailable, instances may fail to start or refresh, so caching and sensible fallbacks are essential. Securing access to configuration, especially secrets, is mandatory. Runtime changes are powerful but risky; a bad value can affect every instance at once, so versioning, validation, and staged rollout matter.
The benefits are consistency, auditable change management, and decoupling configuration from deployment.
Related Patterns
It commonly stores trust settings for Federated Identity and per-stamp values for Deployment Stamps. Feature Flags are a specialized form of externalized configuration for toggling behavior dynamically.
Example
A fleet of microservices reads its settings from Azure App Configuration, with secrets referenced from Key Vault. Each service caches values and refreshes every 30 seconds. To lower a rate limit across the fleet, an operator updates one key; within seconds all instances pick up the new value, with no redeployment. The store keeps a version history, so a bad change can be rolled back quickly.