Correlation IDs in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Correlation IDs in Microservices

What is the main purpose of using correlation IDs in a microservices architecture?

A To uniquely identify and trace a request as it travels through multiple microservices.

B To encrypt data between microservices for security purposes.

C To balance the load evenly across all microservices instances.

D To store user session data centrally for all microservices.

💡 Hint

Think about how you can follow a single request across different services.

Correlation IDs help track a single request across multiple microservices, making debugging and monitoring easier.

❓ Architecture

intermediate

Where to Generate Correlation IDs

In a microservices system, where is the best place to generate a correlation ID for a client request?

A At the client side before sending the request.

B At every microservice independently when processing the request.

C Only in the database when storing the request data.

D At the first entry point or API gateway that receives the client request.

💡 Hint

Consider where the request first enters the system.

Generating the correlation ID at the first entry point ensures all downstream services use the same ID for tracing.

❓ scaling

advanced

Handling Correlation IDs in Asynchronous Messaging

How should correlation IDs be handled when microservices communicate asynchronously via message queues?

A Include the correlation ID in the message headers so the receiving service can continue tracing.

B Generate a new correlation ID for each message to avoid confusion.

C Do not use correlation IDs in asynchronous communication as they are only for HTTP requests.

D Store correlation IDs only in the database and not in messages.

💡 Hint

Think about how tracing continues across asynchronous boundaries.

Passing correlation IDs in message headers allows tracing across asynchronous calls just like synchronous ones.

❓ tradeoff

advanced

Tradeoffs of Using Correlation IDs in Logs

What is a potential tradeoff when including correlation IDs in every log entry across microservices?

A Including correlation IDs slows down the network communication between services.

B Correlation IDs cause security vulnerabilities by exposing sensitive data.

C Logs become larger and may increase storage and processing costs.

D Correlation IDs make logs unreadable and useless for debugging.

💡 Hint

Consider the impact on log size and storage.

Adding correlation IDs to logs increases log size, which can raise storage and processing costs, but improves traceability.

❓ estimation

expert

Estimating Correlation ID Storage Impact

A microservices system processes 1 million requests per hour. Each request generates logs in 5 services, each log entry includes a 36-character UUID correlation ID. Estimate the additional storage needed per hour just for storing correlation IDs in logs, assuming each log entry stores only the correlation ID as a string (1 character = 1 byte).

A Approximately 36 MB per hour

B Approximately 180 MB per hour

C Approximately 720 MB per hour

D Approximately 5 MB per hour

💡 Hint

Calculate total log entries and multiply by correlation ID size in bytes.

1 million requests × 5 logs = 5 million entries. Each entry 36 bytes. Total = 5,000,000 × 36 = 180,000,000 bytes ≈ 180 MB.

Practice

1. What is the primary purpose of a Correlation ID in microservices?

easy

A. To balance load between servers

B. To encrypt data between services

C. To track a single request across multiple services for easier debugging

D. To store user session information

Solution

1. Step 1: Understand the role of Correlation ID

   A Correlation ID is a unique identifier attached to a request that travels through multiple services.

2. Step 2: Identify its main use

   This ID helps developers trace and debug the flow of that request across distributed systems.

3. Final Answer:

   To track a single request across multiple services for easier debugging -> Option C

4. Quick Check:

   Correlation ID = request tracking [OK]

Hint: Correlation ID links logs of one request across services [OK]

Common Mistakes:

• Confusing Correlation ID with encryption keys
• Thinking it balances load
• Assuming it stores user data

2. Which of the following is the correct way to pass a Correlation ID between microservices?

easy

A. Add it as a custom HTTP header in the request

B. Include it as a query parameter in the URL

C. Store it in a database before each call

D. Embed it inside the response body

Solution

1. Step 1: Review common practices for passing metadata

   Metadata like Correlation IDs are typically passed in HTTP headers to keep requests clean and consistent.

2. Step 2: Evaluate options

   Query parameters can be altered or logged insecurely; storing in DB is inefficient; response body is too late for tracking.

3. Final Answer:

   Add it as a custom HTTP header in the request -> Option A

4. Quick Check:

   Correlation ID in headers = best practice [OK]

Hint: Use HTTP headers to pass Correlation IDs [OK]

Common Mistakes:

• Using query parameters which can be insecure
• Storing IDs in database for each call
• Embedding IDs in response body instead of request

3. Consider this simplified code snippet in a microservice receiving an HTTP request:

def handle_request(request):
    correlation_id = request.headers.get('X-Correlation-ID')
    log(f"Start processing request {correlation_id}")
    # ... process ...
    log(f"End processing request {correlation_id}")

What will be logged if the incoming request has header X-Correlation-ID: abc123?

medium

A. No logs will be generated

B. Start processing request abc123
End processing request abc123

C. Start processing request X-Correlation-ID
End processing request X-Correlation-ID

D. Start processing request None
End processing request None

Solution

1. Step 1: Extract Correlation ID from headers

   The code uses request.headers.get('X-Correlation-ID') which returns the header value if present.

2. Step 2: Check the header value in the request

   The request has X-Correlation-ID: abc123, so correlation_id will be 'abc123'.

3. Final Answer:

   Start processing request abc123 End processing request abc123 -> Option B

4. Quick Check:

   Header value read correctly = logs with abc123 [OK]

Hint: Headers.get returns value or None; here value exists [OK]

Common Mistakes:

• Assuming header key is logged instead of value
• Thinking None is logged when header exists
• Believing no logs are generated

4. A developer notices that Correlation IDs are missing in logs of downstream services. Which is the most likely cause?

medium

A. The Correlation ID header is not forwarded in outgoing requests

B. The Correlation ID is too long and gets truncated

C. The logging system does not support string messages

D. The services are using different programming languages

Solution

1. Step 1: Understand Correlation ID propagation

   Correlation IDs must be passed along with every outgoing request to maintain traceability.

2. Step 2: Identify common propagation mistake

   If downstream logs miss the ID, it usually means the header was not forwarded properly.

3. Final Answer:

   The Correlation ID header is not forwarded in outgoing requests -> Option A

4. Quick Check:

   Missing ID in logs = header not forwarded [OK]

Hint: Always forward Correlation ID header downstream [OK]

Common Mistakes:

• Blaming length truncation without evidence
• Assuming logging system limitation
• Thinking language differences cause missing IDs

5. You design a microservices system where each service generates its own Correlation ID if none is provided. What is a potential problem with this approach?

hard

A. It ensures better security by hiding original IDs

B. It improves performance by reducing header size

C. It simplifies logging by having unique IDs per service

D. It breaks the traceability because multiple IDs exist for the same request

Solution

1. Step 1: Analyze the effect of generating new IDs per service

   If each service creates a new Correlation ID, the original request's trace is lost.

2. Step 2: Understand impact on traceability

   Multiple different IDs for one request make it impossible to follow the full request path across services.

3. Final Answer:

   It breaks the traceability because multiple IDs exist for the same request -> Option D

4. Quick Check:

   Multiple IDs = broken traceability [OK]

Hint: One Correlation ID per request across services only [OK]

Common Mistakes:

• Thinking multiple IDs improve security
• Assuming performance improves with new IDs
• Believing unique IDs per service simplify logs