REST API between services in Microservices - Architecture Diagram

System Overview - REST API between services

This system shows how multiple microservices communicate using REST APIs. Each service exposes endpoints that other services call over HTTP. The design ensures clear separation of concerns, scalability, and easy maintenance.

Key requirements include reliable inter-service communication, load balancing, and caching to improve performance.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  +-------------------+
  |                   |
  v                   v
Service A           Service B
  |                   |
  v                   v
Cache A             Cache B
  |                   |
  v                   v
Database A          Database B

Components

User

client

Initiates requests to the system

Load Balancer

load_balancer

Distributes incoming requests evenly across API Gateway instances

API Gateway

api_gateway

Routes requests to appropriate microservices and handles authentication

Service A

service

Handles specific business logic and exposes REST API endpoints

Service B

service

Handles another business domain and exposes REST API endpoints

Cache A

cache

Stores frequently accessed data for Service A to reduce database load

Cache B

cache

Stores frequently accessed data for Service B to reduce database load

Database A

database

Persistent storage for Service A data

Database B

database

Persistent storage for Service B data

Request Flow - 11 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Service A

Service A → Cache A

Cache A → Service A

Service A → Database A

Database A → Service A

Service A → Cache A

Service A → API Gateway

API Gateway → Load Balancer

Load Balancer → User

Failure Scenario

Component Fails:Cache A

Impact:Service A experiences higher latency due to cache misses; database load increases

Mitigation:Service A falls back to querying Database A directly; cache is rebuilt asynchronously

Architecture Quiz - 3 Questions

Which component routes requests to the correct microservice?

A Load Balancer

B API Gateway

C Cache

D Database

Design Principle

This architecture demonstrates how REST APIs enable microservices to communicate clearly and independently. Using an API Gateway centralizes routing and security. Caches improve performance by reducing database load. Load balancers ensure scalability and availability.

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