Lessons from microservices failures - System Design Exercise

Design: Microservices Architecture Lessons

Focus on microservices failure causes and mitigation strategies including architecture, communication, data management, and deployment. Out of scope: detailed implementation of each microservice business logic.

Functional Requirements

FR1: Understand common failure points in microservices systems

FR2: Identify causes of failures such as cascading failures, data inconsistency, and deployment issues

FR3: Learn best practices to prevent or mitigate these failures

FR4: Design a resilient microservices system incorporating these lessons

Non-Functional Requirements

NFR1: System should handle 10,000 concurrent requests with p99 latency under 300ms

NFR2: Availability target of 99.9% uptime (less than 8.77 hours downtime per year)

NFR3: Support eventual consistency where applicable

NFR4: Allow independent deployment of services without downtime

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

Load Balancer

Circuit Breaker

Message Queue

Centralized Logging and Monitoring

Database per Service

Deployment Pipeline with Canary Releases

Design Patterns

Circuit Breaker Pattern

Bulkhead Isolation

Eventual Consistency with Event Sourcing

Retry with Exponential Backoff

Blue-Green and Canary Deployments

Centralized Logging and Distributed Tracing

Reference Architecture

                +--------------------+
                |    API Gateway     |
                +---------+----------+
                          |
          +---------------+----------------+
          |                                |
  +-------v-------+                +-------v-------+
  |  Service A    |                |  Service B    |
  +-------+-------+                +-------+-------+
          |                                |
  +-------v-------+                +-------v-------+
  | Database A    |                | Database B    |
  +---------------+                +---------------+
          |                                |
  +-------v----------------+  +--------v----------------+
  | Message Queue (Events)  |  | Circuit Breaker & Retry |
  +------------------------+  +-------------------------+

Additional components:
+-------------------------+
| Centralized Logging &    |
| Monitoring System        |
+-------------------------+

Components

API Gateway

Nginx, Kong, or AWS API Gateway

Entry point for client requests, routes to appropriate services, handles authentication and rate limiting

Service Registry and Discovery

Consul, Eureka

Keeps track of available service instances for dynamic routing

Circuit Breaker

Hystrix, Resilience4j

Prevents cascading failures by stopping calls to failing services

Message Queue

Kafka, RabbitMQ

Enables asynchronous communication and event-driven architecture for eventual consistency

Centralized Logging and Monitoring

ELK Stack, Prometheus, Grafana

Collects logs and metrics for quick failure detection and troubleshooting

Database per Service

PostgreSQL, MongoDB per service

Ensures data ownership and reduces coupling between services

Deployment Pipeline

Jenkins, GitHub Actions, Spinnaker

Supports automated testing and safe deployments using blue-green or canary strategies

Request Flow

1. Client sends request to API Gateway.

2. API Gateway routes request to appropriate microservice based on URL and service registry.

3. Microservice processes request, reads/writes its own database.

4. If operation requires notifying other services, microservice publishes event to message queue.

5. Other services consume events asynchronously to update their state, ensuring eventual consistency.

6. Circuit breaker monitors service calls; if failures exceed threshold, it trips to prevent further calls.

7. Centralized logging collects logs and metrics from all services for monitoring and alerting.

8. Deployment pipeline enables independent service updates with minimal downtime using canary releases.

Database Schema

Each microservice owns its own database schema. For example: - Service A Database: Table Users(user_id PK, name, email) - Service B Database: Table Orders(order_id PK, user_id FK, product_id, status) Relationships between services are managed via events, not direct DB joins, to reduce coupling.

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure or bottleneck under high load

Service-to-service synchronous calls causing cascading failures

Database contention or scaling limits per service

Message queue overload or slow consumers causing event backlog

Deployment errors causing downtime or inconsistent states

Solutions

Use multiple API Gateway instances behind a load balancer for high availability

Implement circuit breakers and bulkheads to isolate failures and prevent cascading

Use database sharding or read replicas to scale databases per service

Scale message queue clusters and optimize consumer throughput; use backpressure mechanisms

Adopt blue-green or canary deployments with automated rollback on failure

Interview Tips

Time: Spend 10 minutes understanding failure causes and clarifying requirements, 20 minutes designing a resilient microservices architecture with failure mitigation, and 15 minutes discussing scaling and operational best practices.

Explain common microservices failure modes like cascading failures and data inconsistency

Describe how patterns like circuit breaker and bulkhead improve resilience

Emphasize importance of asynchronous communication and eventual consistency

Discuss deployment strategies that reduce downtime and risk

Highlight monitoring and alerting as critical for quick failure detection