Environment configuration in Microservices - Architecture Diagram

System Overview - Environment configuration

This system manages environment configuration for a microservices architecture. It ensures that each microservice receives the correct settings for different environments like development, testing, and production. The system supports secure, centralized configuration management with version control and dynamic updates.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
+-------------------+       +---------------------+
| Configuration      |<----->| Configuration Store |
| Service           |       | (e.g., Consul, etcd) |
+-------------------+       +---------------------+
  |
  v
Microservices (Service A, B, C)
  |
  v
Databases

Cache Layer (e.g., Redis) connected between Configuration Store and Configuration Service for fast reads

Components

User

client

Initiates requests to microservices

Load Balancer

load_balancer

Distributes incoming requests evenly across API Gateway instances

API Gateway

api_gateway

Routes requests to appropriate microservices and configuration service

Configuration Service

service

Provides environment configuration data to microservices securely and dynamically

Configuration Store

database

Centralized storage for environment configuration data with versioning

Cache Layer

cache

Caches configuration data to reduce latency and load on Configuration Store

Microservices (Service A, B, C)

service

Consume configuration data to operate correctly in different environments

Databases

database

Store application data for microservices

Request Flow - 14 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Microservices (Service A, B, C)

Microservices (Service A, B, C) → Configuration Service

Configuration Service → Cache Layer

Cache Layer → Configuration Service

Configuration Service → Configuration Store

Configuration Store → Configuration Service

Configuration Service → Cache Layer

Configuration Service → Microservices (Service A, B, C)

Microservices (Service A, B, C) → Databases

Microservices (Service A, B, C) → API Gateway

API Gateway → Load Balancer

Load Balancer → User

Failure Scenario

Component Fails:Configuration Store

Impact:New configuration updates cannot be retrieved; microservices may use stale config from cache or fail if cache is empty

Mitigation:Use replicated Configuration Store with failover; cache serves stale config temporarily; alert operators to fix store

Architecture Quiz - 3 Questions

Which component is responsible for providing environment configuration data to microservices?

A Configuration Service

B API Gateway

C Load Balancer

D Cache Layer

Design Principle

This architecture demonstrates centralized environment configuration management with caching to reduce latency and improve availability. It separates configuration concerns from business logic, enabling dynamic updates and environment-specific settings while maintaining scalability and fault tolerance.

Practice

1. What is the main purpose of environment configuration in microservices?

easy

A. To write all configuration directly inside the code

B. To hardcode database credentials in the source files

C. To separate settings from code for easier management

D. To avoid using any configuration for faster deployment

Solution

1. Step 1: Understand environment configuration role

   Environment configuration means keeping settings like URLs, credentials, and flags outside the code.

2. Step 2: Identify benefits of separating settings

   This separation allows the same code to run in different environments (dev, test, prod) safely and easily.

3. Final Answer:

   To separate settings from code for easier management -> Option C

4. Quick Check:

   Settings separate from code = B [OK]

Hint: Settings outside code means environment configuration [OK]

Common Mistakes:

• Confusing configuration with code logic
• Hardcoding sensitive data inside source files
• Ignoring environment differences

2. Which of the following is the correct way to access an environment variable named DB_HOST in a microservice?

easy

A. getEnv('DB_HOST')

B. config.get('DB_HOST')

C. env.DB_HOST()

D. process.env.DB_HOST

Solution

1. Step 1: Identify common environment variable access syntax

   In many microservice platforms, environment variables are accessed via process.env.VARIABLE_NAME.

2. Step 2: Match the correct syntax for DB_HOST

   The correct way is process.env.DB_HOST, which reads the variable from the environment.

3. Final Answer:

   process.env.DB_HOST -> Option D

4. Quick Check:

   Environment variables use process.env = A [OK]

Hint: Use process.env.VAR to read environment variables [OK]

Common Mistakes:

• Using function calls instead of direct access
• Confusing config libraries with environment variables
• Using incorrect object names like env or getEnv

3. Given this code snippet in a microservice:

const port = process.env.PORT || 3000;
console.log(port);

If the environment variable PORT is set to 8080, what will be printed?

medium

A. 8080

B. undefined

C. null

D. 3000

Solution

1. Step 1: Understand the fallback logic

   The code uses process.env.PORT || 3000, meaning if PORT is set, use it; otherwise, use 3000.

2. Step 2: Apply the given environment variable value

   Since PORT is set to 8080, the variable port will be 8080.

3. Final Answer:

   8080 -> Option A

4. Quick Check:

   PORT set to 8080 means output 8080 [OK]

Hint: If env var exists, use it; else fallback value [OK]

Common Mistakes:

• Assuming fallback value always prints
• Confusing undefined with fallback
• Ignoring environment variable presence

4. A microservice fails to read environment variables after deployment. Which is the most likely cause?

medium

A. Environment variables were not set in the deployment environment

B. The code uses process.env to read variables

C. The microservice has no network connection

D. The source code has syntax errors unrelated to config

Solution

1. Step 1: Identify common reasons for missing environment variables

   If the microservice cannot read environment variables, often they were not set or loaded properly in the deployment environment.

2. Step 2: Eliminate other options

   Using process.env is correct syntax; network issues or unrelated syntax errors won't cause missing env vars.

3. Final Answer:

   Environment variables were not set in the deployment environment -> Option A

4. Quick Check:

   Missing env vars usually mean not set in environment [OK]

Hint: Check if env vars are set in deployment environment [OK]

Common Mistakes:

• Blaming code syntax for missing env vars
• Ignoring deployment environment setup
• Assuming network issues cause env var problems

5. You want to deploy the same microservice code to development, staging, and production environments. Which approach best uses environment configuration to handle different database URLs safely?

hard

A. Hardcode all database URLs in the source code and comment/uncomment as needed

B. Use environment variables to set the database URL for each environment separately

C. Store all database URLs in a single config file checked into source control

D. Use a random database URL generated at runtime

Solution

1. Step 1: Understand the need for environment-specific settings

   Each environment (dev, staging, prod) has different database URLs for safety and isolation.

2. Step 2: Choose a method that separates config from code and supports environment differences

   Using environment variables allows setting different URLs without changing code or risking secrets in source control.

3. Step 3: Evaluate other options

   Hardcoding or single config files risk errors and security issues; random URLs are impractical.

4. Final Answer:

   Use environment variables to set the database URL for each environment separately -> Option B

5. Quick Check:

   Env vars per environment = safe config management [OK]

Hint: Use env vars for environment-specific secrets and URLs [OK]

Common Mistakes:

• Hardcoding secrets in code
• Checking sensitive config into source control
• Using random or unsafe config values