Hackforge Academy

Explanation

Centralized Configuration Management means storing application configuration in a central location instead of keeping separate configuration values inside every microservice. Configuration can include database URLs, API endpoints, feature flags, service URLs, and application settings. In a microservices architecture, centralized configuration makes it easier to manage configuration consistently across multiple services and environments such as development, testing, and production.

Code:

# Instead of hardcoding configuration in every service:

DATABASE_URL = 'postgresql://localhost/company'
PRODUCT_SERVICE_URL = 'http://localhost:8001'
PAYMENT_SERVICE_URL = 'http://localhost:8002'


# Configuration can be centralized:
# config/
#   development.env
#   testing.env
#   production.env

Explanation

Environment variables are a simple and common way to externalize configuration from Python applications. The os module can read environment variables using os.getenv(). Sensitive values such as passwords, API keys, and secret keys should not be hardcoded in source code. Different environments can provide different configuration values while using the same application code.

Code:

import os

DATABASE_URL = os.getenv(
    'DATABASE_URL',
    'sqlite:///app.db'
)

PRODUCT_SERVICE_URL = os.getenv(
    'PRODUCT_SERVICE_URL',
    'http://localhost:8001'
)

print('Database:', DATABASE_URL)
print('Product Service:', PRODUCT_SERVICE_URL)

Explanation

A .env file can store environment-specific configuration values during local development. Python applications can use the python-dotenv package to load these values into environment variables. This keeps configuration separate from application code. The .env file should normally be added to .gitignore when it contains passwords, API keys, or other secrets. Production systems should use a secure secret or configuration management system instead of committing sensitive configuration to source control.

Code:

# Install:
# pip install python-dotenv

# .env
# DATABASE_URL=postgresql://localhost/company
# PRODUCT_SERVICE_URL=http://localhost:8001
# API_KEY=my-secret-key

from dotenv import load_dotenv
import os

load_dotenv()

DATABASE_URL = os.getenv('DATABASE_URL')
PRODUCT_SERVICE_URL = os.getenv('PRODUCT_SERVICE_URL')
API_KEY = os.getenv('API_KEY')

print(DATABASE_URL)
print(PRODUCT_SERVICE_URL)

Explanation

FastAPI applications can use Pydantic Settings to define configuration in a structured and type-safe way. Configuration values can be loaded from environment variables and .env files. This approach keeps configuration logic in one place and allows the rest of the application to access validated settings through a settings object. It is especially useful for microservices because each service can use the same configuration pattern while providing different environment-specific values.

Code:

# Install:
# pip install pydantic-settings

from pydantic_settings import BaseSettings, SettingsConfigDict


class Settings(BaseSettings):
    database_url: str
    product_service_url: str
    debug: bool = False

    model_config = SettingsConfigDict(
        env_file='.env'
    )


settings = Settings()

print(settings.database_url)
print(settings.product_service_url)
print(settings.debug)

Explanation

In a larger microservices architecture, a dedicated configuration service can provide configuration to multiple services. For example, User Service, Product Service, Order Service, and Payment Service can retrieve their configuration from a centralized configuration system. This avoids duplicating configuration across services and makes configuration changes easier to manage. Production environments may use tools such as Consul, Kubernetes ConfigMaps and Secrets, HashiCorp Vault, or cloud configuration services. Sensitive credentials should be stored using a secrets-management mechanism rather than plain configuration files.

Code:

# Centralized Configuration Architecture
#
#                 Configuration Store
#                         |
#          +--------------+--------------+
#          |              |              |
#          v              v              v
#    User Service   Product Service   Order Service
#
# Example configuration:
#
# product-service-url = http://product-service:8001
# database-url        = postgresql://...
# log-level           = INFO
# feature-payment     = true
#
# Each service loads configuration
# instead of hardcoding these values.