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

Practice

1. Which of the following is a key characteristic of microservices architecture?

easy

A. Services must be written in the same programming language

B. All services share a single database schema

C. Each service is independently deployable and scalable

D. Microservices require a monolithic deployment

Solution

1. Step 1: Understand microservices independence

   Microservices are designed to be independent units that can be deployed and scaled separately.

2. Step 2: Evaluate options against microservices principles

   Sharing a single database or requiring the same language contradicts microservices flexibility. Monolithic deployment is opposite to microservices.

3. Final Answer:

   Each service is independently deployable and scalable -> Option C

4. Quick Check:

   Independent deployability = C [OK]

Hint: Microservices = independent small services [OK]

Common Mistakes:

• Thinking all services share one database
• Assuming same language is mandatory
• Confusing microservices with monolith

2. Which syntax correctly describes a microservice's responsibility?

easy

A. A microservice focuses on a single business capability

B. A microservice handles multiple unrelated business functions

C. A microservice must handle all user interface logic

D. A microservice should not communicate with other services

Solution

1. Step 1: Identify microservice scope

   Microservices are designed to focus on a single business capability or function.

2. Step 2: Check options for correctness

   Handling multiple unrelated functions or all UI logic is against microservices principles. Communication between services is common and necessary.

3. Final Answer:

   A microservice focuses on a single business capability -> Option A

4. Quick Check:

   Single responsibility = A [OK]

Hint: Microservice = one focused job [OK]

Common Mistakes:

• Thinking microservices do many unrelated tasks
• Believing microservices handle all UI logic
• Ignoring inter-service communication

3. Consider a microservices system where Service A calls Service B, which calls Service C. If Service B fails, what is the expected behavior in a well-designed microservices architecture?

medium

A. Service A receives an error or fallback response quickly

B. All services restart automatically

C. Service C retries the request automatically

D. Service A waits indefinitely for Service B

Solution

1. Step 1: Understand failure handling in microservices

   Microservices use timeouts and fallbacks to avoid waiting indefinitely when a service fails.

2. Step 2: Analyze options for expected behavior

   Waiting indefinitely is bad design. Service C retrying is unrelated to Service B failure. Automatic restart is not immediate failure handling.

3. Final Answer:

   Service A receives an error or fallback response quickly -> Option A

4. Quick Check:

   Timeouts and fallbacks = D [OK]

Hint: Microservices use timeouts, not infinite waits [OK]

Common Mistakes:

• Assuming infinite wait on failure
• Confusing retry logic location
• Expecting automatic restart as immediate fix

4. A developer notices that two microservices share the same database schema directly. What is the main issue with this design?

medium

A. It improves service independence

B. It creates tight coupling between services

C. It reduces data consistency

D. It simplifies service deployment

Solution

1. Step 1: Understand database ownership in microservices

   Each microservice should own its own database to avoid tight coupling.

2. Step 2: Evaluate the impact of shared schema

   Sharing schema creates tight coupling, reducing independence and flexibility. It does not improve independence or simplify deployment.

3. Final Answer:

   It creates tight coupling between services -> Option B

4. Quick Check:

   Shared DB = tight coupling = A [OK]

Hint: Microservices own separate databases [OK]

Common Mistakes:

• Thinking shared DB improves independence
• Assuming shared DB reduces consistency
• Believing shared DB simplifies deployment

5. You are designing a microservices system for an online store. Which approach best supports independent scaling and deployment of the payment and product catalog services?

hard

A. Combine payment and catalog into one service with shared database

B. Deploy payment and catalog as separate modules in the same service

C. Use a single monolithic app for both payment and catalog

D. Separate payment and catalog into distinct services with own databases and APIs

Solution

1. Step 1: Identify microservices best practices for scaling

   Independent services with own databases and APIs allow separate scaling and deployment.

2. Step 2: Compare options for independence and scalability

   Combining services or modules reduces independence. Monolith prevents separate scaling.

3. Final Answer:

   Separate payment and catalog into distinct services with own databases and APIs -> Option D

4. Quick Check:

   Separate services + DBs = B [OK]

Hint: Separate services with own DBs for scaling [OK]

Common Mistakes:

• Combining unrelated services
• Using monolith for microservices goals
• Deploying modules inside one service