Microservices · Lesson 10

Centralized Configuration

Managing Configuration Across Services

Centralized configuration gives distributed services a consistent way to load environment-specific settings. It separates deploy-time values from application code and makes changes auditable. Secrets still require a dedicated secret manager and strict access control.

Reading Typed Settings

Configuration should be parsed and validated at startup so a service fails clearly rather than behaving incorrectly later.

public record CourseServiceSettings(String databaseUrl, int requestTimeoutMs) {
    public static CourseServiceSettings fromEnvironment() {
        String databaseUrl = System.getenv().getOrDefault("DATABASE_URL", "jdbc:h2:mem:academy");
        int timeout = Integer.parseInt(System.getenv().getOrDefault("REQUEST_TIMEOUT_MS", "2000"));
        if (timeout <= 0) throw new IllegalArgumentException("Timeout must be positive");
        return new CourseServiceSettings(databaseUrl, timeout);
    }

    public static void main(String[] arguments) {
        System.out.println(CourseServiceSettings.fromEnvironment());
    }
}

Configuration Categories

Common Mistake and Practices

Common Mistake: Refreshing configuration silently without considering in-flight requests. A partial update can leave related settings inconsistent across instances.

• Validate settings at startup.
• Separate secrets from ordinary configuration.
• Version and review changes.
• Roll out changes gradually.
• Expose safe configuration diagnostics.

Real-World Use Case

All academy services read a shared timeout policy and environment-specific service URLs, while credentials come from a secret manager. Operators can update a feature flag without rebuilding application binaries.