External Configuration Store Pattern

Overview

The External Configuration Store Pattern moves application settings out of deployment artifacts and into a dedicated configuration service. This allows you to change behavior without rebuilding images, supports multiple environments from the same artifact, and enables dynamic updates at runtime.

This pattern is essential for cloud-native and microservices systems where hard-coded configuration creates deployment friction and security risks.

When to Use

Use this pattern when:

• You deploy the same artifact to development, staging, and production
• You need to update settings without redeploying or restarting services
• Secrets or environment-specific values must be kept outside source code
• You want to audit configuration changes centrally
• You manage many services that share common settings or feature flags

Solution

// Application reads configuration from an external store at startup
const config = await fetchConfigFromStore({
  store: 'https://config.example.com',
  application: 'orders-service',
  environment: process.env.ENVIRONMENT,
});

const dbUrl = config['database.url'];
const featureEnabled = config['feature.checkout.v2'] === 'true';

# Example: Kubernetes ConfigMap mounted as environment variables
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  CACHE_TTL: "300"
  FEATURE_FLAGS: "new-ui,beta-search"
---
apiVersion: v1
kind: Pod
spec:
  containers:
    - name: app
      envFrom:
        - configMapRef:
            name: app-config

Explanation

The pattern separates configuration from code. The application starts by loading settings from an external source such as a key-value store, secret manager, ConfigMap, or dedicated configuration service. Settings can be refreshed periodically or pushed to the application when they change.

A typical external configuration system includes:

• Configuration store: a durable source of truth for settings and secrets
• Access layer: API, SDK, or file mount that exposes values to the application
• Environment scoping: separate namespaces or keys for dev, staging, and production
• Change propagation: refresh mechanism or event bus to push updates
• Auditing: logs of who changed what and when

Variants

Variant	Store	Best For
Environment variables	OS process env	Simple containers and local development
ConfigMap / Secrets	Kubernetes objects	Native K8s workloads
Dedicated config service	Consul, Spring Cloud Config, AWS AppConfig	Centralized management and dynamic updates
Secret manager	HashiCorp Vault, AWS Secrets Manager	Sensitive credentials and rotation
Feature flag service	LaunchDarkly, Unleash	Gradual rollouts and experiments

Best Practices

• Keep secrets separate from non-sensitive configuration
• Use environment-specific namespaces to avoid accidental overrides
• Version configuration changes and keep an audit trail
• Fail safely when the external store is unavailable; cache last known values
• Encrypt sensitive values at rest and in transit
• Validate configuration at startup and report clear errors for missing keys

Common Mistakes

• Storing secrets as plain text in configuration files or repositories
• Making the application unable to start if the configuration store is down
• Mixing environment-specific values in the same namespace without scoping
• Forgetting to restart or refresh caches after configuration changes
• Granting overly broad access to the configuration store

Frequently Asked Questions

Q: Does this pattern require a dedicated configuration service? A: No. You can start with environment variables, ConfigMaps, or a secrets manager. A dedicated service adds centralization and dynamic updates as you scale.

Q: How do I update configuration without restarting the application? A: Poll the store on an interval, use a watch mechanism, or push change events through a message bus. Update in-memory caches only after validation.

Q: Are environment variables still part of this pattern? A: Yes, environment variables can be an external configuration store. The key idea is that values live outside the application artifact, not the specific technology.