Why advanced patterns solve edge cases in Microservices - Design It to Understand It

Design: Microservices Edge Case Handling

Focus on microservices communication patterns and fault tolerance. Out of scope: UI design, database internal optimizations.

Functional Requirements

FR1: Support multiple microservices communicating reliably

FR2: Handle failures gracefully without data loss

FR3: Ensure data consistency across services

FR4: Manage service discovery and load balancing

FR5: Allow for scaling and independent deployment

Non-Functional Requirements

NFR1: System must handle 10,000 requests per second

NFR2: API response latency p99 under 300ms

NFR3: Availability target 99.9% uptime

NFR4: Services may fail or be temporarily unreachable

NFR5: Data consistency must be eventual but predictable

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway

Service Registry and Discovery

Message Broker or Event Bus

Circuit Breaker

Retry Mechanism

Saga Pattern Coordinator

Load Balancer

Monitoring and Logging

Design Patterns

Circuit Breaker Pattern

Retry Pattern with Exponential Backoff

Saga Pattern for distributed transactions

Bulkhead Pattern for isolation

Event Sourcing and CQRS

Service Mesh for observability and control

Reference Architecture

Client
  |
  v
API Gateway
  |
  v
+-------------------+       +-------------------+
|  Service Registry  |<----->|  Microservice A    |
+-------------------+       +-------------------+
          |                          |
          v                          v
   +--------------+          +--------------+
   | Message Bus  |<-------->| Microservice B|
   +--------------+          +--------------+
          |
          v
   +----------------+
   | Saga Coordinator|
   +----------------+

Components

API Gateway

Nginx or Kong

Entry point for clients, routes requests to microservices, handles authentication and rate limiting

Service Registry

Consul or Eureka

Keeps track of available microservices and their locations for discovery

Message Bus

Kafka or RabbitMQ

Enables asynchronous communication and event-driven patterns between services

Microservices

Spring Boot / Node.js / Go

Independent services handling specific business capabilities

Saga Coordinator

Custom or framework-based (e.g., Axon Framework)

Manages distributed transactions across services to maintain data consistency

Circuit Breaker

Resilience4j or Hystrix

Prevents cascading failures by stopping calls to failing services temporarily

Request Flow

1. Client sends request to API Gateway

2. API Gateway routes request to appropriate microservice using Service Registry

3. Microservice processes request; if it needs to call other services, it publishes events to Message Bus

4. Other microservices consume events asynchronously and perform their tasks

5. Saga Coordinator tracks distributed transaction steps and triggers compensating actions if needed

6. Circuit Breaker monitors service health and opens to prevent calls to failing services

7. Retries with exponential backoff are used for transient failures

8. Responses flow back through API Gateway to client

Database Schema

Entities are decentralized per microservice. Key entities include: - Order (Microservice A) - Payment (Microservice B) - Event Log (for event sourcing) Relationships are managed via events and sagas rather than direct foreign keys to maintain loose coupling.

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure under high load

Message Bus overload with too many events

Saga Coordinator complexity and state management

Service Registry latency causing discovery delays

Circuit Breaker misconfiguration causing unnecessary service blocking

Solutions

Deploy multiple API Gateway instances behind a load balancer

Partition and scale Message Bus clusters, use topic sharding

Distribute Saga Coordinator or use stateless choreography where possible

Use caching and replication for Service Registry

Tune Circuit Breaker thresholds carefully and monitor metrics

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying edge cases, 20 minutes designing architecture and explaining patterns, 10 minutes discussing scaling and trade-offs, 5 minutes for questions.

Explain why simple request-response is not enough for microservices

Describe how circuit breakers prevent cascading failures

Show how sagas handle distributed transactions without locking

Discuss retry strategies and their impact on latency

Highlight importance of asynchronous communication for resilience

Mention monitoring and observability for detecting edge cases

Practice

1. Why do advanced microservice design patterns help solve edge cases better than simple designs?

easy

A. They rely only on synchronous calls to ensure order.

B. They reduce the number of microservices to simplify the system.

C. They remove all network communication to avoid latency.

D. They add mechanisms to handle failures and complex interactions reliably.

Solution

1. Step 1: Understand simple design limitations

   Simple microservices often miss handling failures and complex service interactions, leading to errors in edge cases.

2. Step 2: Role of advanced patterns

   Advanced patterns add retries, circuit breakers, event-driven flows, and state management to improve reliability and handle tricky cases.

3. Final Answer:

   They add mechanisms to handle failures and complex interactions reliably. -> Option D

4. Quick Check:

   Advanced patterns = handle failures reliably [OK]

Hint: Advanced patterns add fault tolerance and reliability [OK]

Common Mistakes:

• Thinking advanced patterns reduce microservices count
• Assuming no network communication is possible
• Believing synchronous calls alone solve edge cases

2. Which of the following is a correct syntax for implementing a circuit breaker pattern in microservices?

easy

A. Wrap service calls with a circuit breaker that opens after failures.

B. Call services directly without any error handling.

C. Use a retry loop without tracking failures.

D. Use synchronous calls only to avoid failures.

Solution

1. Step 1: Identify circuit breaker purpose

   Circuit breaker stops calls to failing services after threshold to prevent cascading failures.

2. Step 2: Correct syntax usage

   Wrapping calls with a circuit breaker that opens after failures matches the pattern's intent.

3. Final Answer:

   Wrap service calls with a circuit breaker that opens after failures. -> Option A

4. Quick Check:

   Circuit breaker = wrap calls with failure tracking [OK]

Hint: Circuit breaker wraps calls and tracks failures [OK]

Common Mistakes:

• Ignoring failure tracking in retries
• Calling services without error handling
• Assuming synchronous calls prevent failures

3. Consider this simplified pseudocode for a microservice using a retry pattern:

attempts = 0
max_attempts = 3
while attempts < max_attempts:
    response = call_service()
    if response == 'success':
        return 'done'
    attempts += 1
return 'failed'

What will be the output if the service fails twice then succeeds on the third call?

medium

A. "done"

B. "failed"

C. "success"

D. "error"

Solution

1. Step 1: Trace retry attempts

   First two calls fail, attempts increment to 2. Third call succeeds, returns 'done'.

2. Step 2: Understand loop exit

   Loop exits early on success, so 'done' is returned before max_attempts reached.

3. Final Answer:

   "done" -> Option A

4. Quick Check:

   Retries until success = "done" [OK]

Hint: Success before max attempts returns 'done' [OK]

Common Mistakes:

• Assuming all retries fail and return 'failed'
• Confusing 'success' string with return value
• Ignoring early loop exit on success

4. A microservice uses an event-driven pattern but sometimes events are processed twice causing duplicate actions. What is the best fix?

medium

A. Remove event retries to avoid duplicates.

B. Add idempotency keys to events and check before processing.

C. Switch to synchronous calls only.

D. Ignore duplicates as they are harmless.

Solution

1. Step 1: Identify cause of duplicates

   Retries or network issues can cause events to be delivered multiple times.

2. Step 2: Apply idempotency

   Using unique keys lets the service detect and ignore duplicate events, preventing repeated actions.

3. Final Answer:

   Add idempotency keys to events and check before processing. -> Option B

4. Quick Check:

   Idempotency keys prevent duplicate processing [OK]

Hint: Use idempotency keys to avoid duplicate event effects [OK]

Common Mistakes:

• Removing retries loses fault tolerance
• Switching to sync calls ignores async benefits
• Ignoring duplicates causes inconsistent state

5. You design a microservice system where services must remain available even if dependent services fail intermittently. Which advanced pattern combination best handles this edge case?

hard

A. Synchronous calls with no retries to avoid delays.

B. Single monolithic service to avoid network failures.

C. Circuit breaker with fallback responses and event-driven retries.

D. No error handling to keep code simple.

Solution

1. Step 1: Understand availability needs

   Services must stay responsive despite failures in dependencies.

2. Step 2: Combine patterns for resilience

   Circuit breakers stop calls to failing services, fallback responses provide defaults, and event-driven retries handle eventual success.

3. Final Answer:

   Circuit breaker with fallback responses and event-driven retries. -> Option C

4. Quick Check:

   Combine circuit breaker + fallback + retries for availability [OK]

Hint: Combine circuit breaker, fallback, and retries for resilience [OK]

Common Mistakes:

• Using synchronous calls blocks availability
• Monolith avoids network but loses scalability
• No error handling causes system crashes