Microservices characteristics - System Design Exercise

Design: Microservices Architecture Characteristics

Focus on the core characteristics and design principles of microservices architecture. Out of scope are specific business domain implementations or detailed service logic.

Functional Requirements

FR1: Design a system that breaks a large application into small, independent services

FR2: Each service should own its own data and logic

FR3: Services must communicate over network protocols

FR4: Support independent deployment and scaling of each service

FR5: Ensure fault isolation so failure in one service does not affect others

FR6: Enable technology diversity per service

FR7: Allow teams to develop, deploy, and maintain services independently

Non-Functional Requirements

NFR1: Handle up to 10,000 concurrent users

NFR2: API response latency p99 under 300ms

NFR3: Availability target of 99.9% uptime

NFR4: Services must be loosely coupled

NFR5: Data consistency can be eventual, not always immediate

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway or Service Mesh for communication

Service Registry and Discovery

Load Balancer

Database per service

Message Broker for asynchronous communication

Monitoring and Logging tools

Design Patterns

Database per Service pattern

Circuit Breaker pattern for fault tolerance

API Gateway pattern

Event-Driven Architecture

Service Discovery pattern

Bulkhead pattern for isolation

Reference Architecture

Client
  |
  v
API Gateway
  |
  +---------------------+---------------------+---------------------+
  |                     |                     |                     |
Service A           Service B             Service C
(DB A)              (DB B)                (DB C)
  |                     |                     |
Message Broker (optional for async communication)
  |
Monitoring & Logging System

Components

API Gateway

Nginx, Kong, or AWS API Gateway

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

Service A, B, C

Docker containers running independent microservices

Each service implements a specific business capability with its own database

Databases per Service

PostgreSQL, MongoDB, or other DBs per service

Each service owns and manages its own data to ensure loose coupling

Message Broker

RabbitMQ, Kafka, or AWS SNS/SQS

Supports asynchronous communication and event-driven interactions between services

Service Registry and Discovery

Consul, Eureka, or Kubernetes DNS

Allows services to find each other dynamically

Monitoring and Logging

Prometheus, Grafana, ELK Stack

Tracks service health, logs, and metrics for fault detection and debugging

Request Flow

1. Client sends request to API Gateway

2. API Gateway authenticates and routes request to the appropriate microservice

3. Microservice processes request using its own database

4. If needed, microservice publishes events to Message Broker for other services

5. Other services subscribe and react to events asynchronously

6. API Gateway returns response to client

7. Monitoring system collects metrics and logs from all services

Database Schema

Each microservice has its own database schema tailored to its domain. For example, Service A manages 'Users' table, Service B manages 'Orders' table, Service C manages 'Inventory' table. There is no shared database to avoid tight coupling.

Scaling Discussion

Bottlenecks

API Gateway can become a single point of failure or bottleneck

Database per service may face scaling limits individually

Inter-service communication latency can increase with more services

Monitoring overhead grows with number of services

Data consistency challenges due to eventual consistency

Solutions

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

Scale databases vertically or horizontally; use caching where appropriate

Adopt asynchronous messaging to reduce synchronous calls and latency

Implement centralized logging and distributed tracing to manage monitoring complexity

Design services to tolerate eventual consistency and use patterns like Saga for distributed transactions

Interview Tips

Time: Spend 10 minutes understanding microservices principles and requirements, 15 minutes designing the architecture and data flow, 10 minutes discussing scaling and fault tolerance, and 10 minutes answering questions.

Explain how microservices enable independent deployment and scaling

Discuss data ownership and database per service pattern

Highlight communication methods and fault tolerance patterns

Emphasize monitoring and observability importance

Address challenges like data consistency and API Gateway bottlenecks