REST API between services in Microservices - Scalability & System Analysis

Scalability Analysis - REST API between services

Growth Table: REST API Between Services

Users/Traffic	API Requests per Second	Latency	Service Instances	Network Load	Data Volume
100 users	~50-100 RPS	Low (10-50ms)	1-2 instances per service	Low	Small
10,000 users	~5,000-10,000 RPS	Moderate (50-100ms)	3-5 instances per service	Moderate	Medium
1,000,000 users	~500,000-1,000,000 RPS	Higher (100-200ms)	10+ instances per service, autoscaling	High	Large
100,000,000 users	~50,000,000+ RPS	High (200ms+)	Hundreds of instances, global distribution	Very High	Very Large

First Bottleneck

At low scale, the first bottleneck is usually the API gateway or load balancer handling incoming REST calls. As traffic grows, the service instances CPU and memory become bottlenecks due to request processing. At medium scale, the network bandwidth between services can limit throughput. At very large scale, database or stateful service dependencies accessed via REST APIs become the main bottleneck.

Scaling Solutions

• Horizontal scaling: Add more service instances behind load balancers to distribute REST API calls.
• API Gateway optimization: Use caching, rate limiting, and request aggregation to reduce load.
• Asynchronous communication: Use message queues or event streams to reduce synchronous REST calls.
• Service partitioning: Split services by domain or function to reduce inter-service calls.
• Network improvements: Use faster network links, service mesh with optimized routing.
• Database scaling: Use read replicas, caching layers, and sharding to reduce backend bottlenecks.
• CDN: For REST APIs serving static or cacheable content, use CDN to offload traffic.

Back-of-Envelope Cost Analysis

Assuming 10,000 users generating 10,000 RPS:

• Each server handles ~3,000 RPS -> need ~4 service instances per service.
• Network bandwidth: 10,000 RPS * 1 KB/request = ~10 MB/s per service.
• Storage: Logs and metrics grow with traffic; plan for scalable storage.
• CPU and memory scale linearly with request volume; monitor and autoscale.

Interview Tip

Structure your scalability discussion by:

1. Defining expected traffic and usage patterns.
2. Identifying bottlenecks at each scale step.
3. Proposing targeted solutions for each bottleneck.
4. Considering trade-offs like cost, complexity, and latency.
5. Discussing monitoring and autoscaling strategies.

Self Check

Your database handles 1000 QPS. Traffic grows 10x. What do you do first?

Answer: Add read replicas and implement caching to reduce direct database load before scaling vertically or sharding.

Key Result

REST APIs between services scale well with horizontal service instances and load balancing, but the first bottleneck is usually service CPU and network bandwidth. Database and backend dependencies become bottlenecks at large scale, requiring caching, read replicas, and sharding.

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