REST API between services in Microservices - System Design Exercise

Design: REST API Communication Between Microservices

Design focuses on REST API communication between microservices including security, reliability, and scalability. Out of scope are the internal business logic of services and UI design.

Functional Requirements

FR1: Enable communication between multiple microservices using REST APIs

FR2: Support synchronous request-response interactions

FR3: Ensure secure communication with authentication and authorization

FR4: Handle failures gracefully with retries and timeouts

FR5: Allow versioning of APIs for backward compatibility

FR6: Support monitoring and logging of API calls

Non-Functional Requirements

NFR1: Handle up to 10,000 requests per second between services

NFR2: API response latency p99 under 200ms

NFR3: 99.9% availability for inter-service communication

NFR4: Use stateless REST APIs

NFR5: Support JSON as data format

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 routing and security

Authentication and Authorization service (e.g., OAuth2, JWT)

Load balancers for service endpoints

Retry and timeout mechanisms in client libraries

Centralized logging and monitoring system

API versioning strategy

Design Patterns

Circuit Breaker pattern to handle failures

Retry pattern with exponential backoff

API Gateway pattern for routing and security

Bulkhead pattern to isolate failures

Versioning strategies: URI versioning, header versioning

Reference Architecture

Client Service A  --->  API Gateway  --->  Service B
                     |                  |
                     |                  --->  Service C
                     |
                     --->  Authentication Service

Monitoring & Logging System <--- All Services

Components

API Gateway

Kong / NGINX / Envoy

Routes requests between services, enforces security policies, and handles API versioning

Service A, B, C

Any microservice framework (Spring Boot, Express.js, etc.)

Business logic providers communicating via REST APIs

Authentication Service

OAuth2 Server / JWT Provider

Issues and validates tokens for secure inter-service communication

Load Balancer

AWS ELB / HAProxy

Distributes incoming requests evenly across service instances

Monitoring & Logging

Prometheus, Grafana, ELK Stack

Collects metrics and logs for observability of API calls

Request Flow

1. 1. Service A wants to call Service B's API.

2. 2. Service A obtains a valid JWT token from Authentication Service.

3. 3. Service A sends REST API request with JWT token to API Gateway.

4. 4. API Gateway authenticates the token and routes the request to Service B.

5. 5. Service B processes the request and sends response back to API Gateway.

6. 6. API Gateway forwards the response to Service A.

7. 7. All API calls and responses are logged and monitored.

Database Schema

Not applicable as this design focuses on API communication between services rather than data storage.

Scaling Discussion

Bottlenecks

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

Authentication Service latency affecting request throughput

Network latency between services impacting response times

Logging and monitoring systems overwhelmed by high volume of API calls

Solutions

Deploy API Gateway in a highly available cluster with autoscaling

Cache authentication tokens locally to reduce calls to Authentication Service

Use service mesh with sidecar proxies to optimize communication and retries

Implement sampling and aggregation in logging to reduce volume

Use CDN or edge caching for static API responses where possible

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling and trade-offs, and 5 minutes summarizing.

Explain the choice of REST APIs for synchronous communication

Discuss security with JWT and OAuth2 tokens

Highlight the role of API Gateway in routing and versioning

Describe failure handling with retries and circuit breakers

Mention monitoring and logging importance for observability

Address scaling challenges and solutions clearly

Practice

1. What is the main purpose of using a REST API between microservices?

easy

A. To allow services to communicate over HTTP using standard methods

B. To store data permanently in a database

C. To run services on the same machine only

D. To replace all backend logic with frontend code

Solution

1. Step 1: Understand REST API role in microservices

   REST APIs enable communication between independent services using HTTP methods like GET, POST, PUT, DELETE.

2. Step 2: Identify the correct purpose

   Storing data or running services on the same machine are not the main goals of REST APIs; they focus on communication.

3. Final Answer:

   To allow services to communicate over HTTP using standard methods -> Option A

4. Quick Check:

   REST API = communication over HTTP [OK]

Hint: REST APIs connect services via HTTP methods [OK]

Common Mistakes:

• Confusing REST API with database storage
• Thinking REST APIs run services locally only
• Assuming REST replaces backend logic

2. Which HTTP method is typically used to update an existing resource in a REST API between microservices?

easy

A. GET

B. PUT

C. POST

D. DELETE

Solution

1. Step 1: Recall HTTP methods and their purposes

   GET retrieves data, POST creates new data, PUT updates existing data, DELETE removes data.

2. Step 2: Match method to update action

   Updating a resource is done with PUT, which replaces or modifies the resource at the given URL.

3. Final Answer:

   PUT -> Option B

4. Quick Check:

   Update = PUT [OK]

Hint: PUT method updates resources in REST APIs [OK]

Common Mistakes:

• Using GET to update data
• Confusing POST with update instead of create
• Using DELETE to update resources

3. Consider this REST API call between two services:

GET /users/123

What is the expected result of this request?

medium

A. Retrieve details of the user with ID 123

B. Create a new user with ID 123

C. Delete the user with ID 123

D. Update the user with ID 123

Solution

1. Step 1: Analyze the HTTP method and URL

   The method is GET, which is used to retrieve data. The URL targets user with ID 123.

2. Step 2: Determine the action based on method

   GET requests fetch data without changing it, so it retrieves user details.

3. Final Answer:

   Retrieve details of the user with ID 123 -> Option A

4. Quick Check:

   GET /users/123 = retrieve user data [OK]

Hint: GET fetches data, not modifies it [OK]

Common Mistakes:

• Thinking GET creates or deletes data
• Confusing URL path with action
• Assuming GET updates resources

4. A microservice sends a POST request to another service's REST API but receives a 405 Method Not Allowed error. What is the most likely cause?

medium

A. The request body is missing required fields

B. The URL endpoint does not exist

C. The HTTP method POST is not supported by the endpoint

D. The server is down

Solution

1. Step 1: Understand 405 Method Not Allowed meaning

   This error means the server recognizes the URL but does not allow the HTTP method used.

2. Step 2: Match error to cause

   If POST is not supported on that endpoint, the server rejects it with 405. Other issues cause different errors.

3. Final Answer:

   The HTTP method POST is not supported by the endpoint -> Option C

4. Quick Check:

   405 error = method not allowed [OK]

Hint: 405 means method not allowed on endpoint [OK]

Common Mistakes:

• Confusing 405 with 404 (not found)
• Assuming missing fields cause 405
• Thinking server down causes 405

5. You design two microservices: Service A calls Service B's REST API to get user data. To improve scalability and reduce latency, which design choice is best?

hard

A. Service A calls Service B synchronously for every user request

B. Service A and B share a database to avoid API calls

C. Service B pushes user data to Service A via REST POST requests

D. Service A caches user data locally and refreshes periodically

Solution

1. Step 1: Evaluate synchronous calls impact

   Calling Service B synchronously for every request adds latency and load, reducing scalability.

2. Step 2: Consider caching benefits

   Caching user data locally in Service A reduces calls to Service B, improving response time and scalability.

3. Step 3: Assess other options

   Service B pushing data is complex and not typical REST usage; sharing a database breaks microservice independence.

4. Final Answer:

   Service A caches user data locally and refreshes periodically -> Option D

5. Quick Check:

   Caching improves scalability and latency [OK]

Hint: Cache data locally to reduce cross-service calls [OK]

Common Mistakes:

• Using synchronous calls for every request
• Sharing databases between microservices
• Expecting REST APIs to push data automatically