REST API design for systems in HLD - Scalability & System Analysis

Scalability Analysis - REST API design for systems

Growth Table: REST API Design for Systems

Users/Traffic	What Changes?
100 users	Single API server handles requests; simple database; no caching needed; low latency.
10,000 users	Need load balancer; multiple API servers; database read replicas; introduce caching layer (e.g., Redis); rate limiting.
1,000,000 users	API servers scaled horizontally with auto-scaling; database sharding; CDN for static content; advanced caching; API gateway for routing and security; asynchronous processing for heavy tasks.
100,000,000 users	Global distributed API servers; multi-region database clusters; aggressive caching and edge computing; microservices split; strict rate limiting and quota management; event-driven architecture for scalability.

First Bottleneck

At small to medium scale, the database is the first bottleneck. It struggles to handle high query rates and concurrent connections from API servers. This causes increased latency and potential downtime.

Scaling Solutions

• Database: Use read replicas to distribute read load; implement connection pooling; shard data by user or region.
• API Servers: Scale horizontally behind a load balancer; use stateless design for easy scaling.
• Caching: Add in-memory caches (Redis/Memcached) to reduce database hits for frequent queries.
• CDN: Serve static content and cache API responses at edge locations to reduce latency.
• API Gateway: Manage routing, authentication, rate limiting, and monitoring centrally.
• Asynchronous Processing: Offload heavy or long-running tasks to background workers or message queues.

Back-of-Envelope Cost Analysis

• At 10,000 users, expect ~1000 QPS (requests per second) assuming 1 request per user per 10 seconds.
• Database needs to handle ~1000 QPS; a single PostgreSQL instance can handle up to ~5000 QPS, so read replicas help.
• API servers: each can handle ~2000 concurrent connections; 3-5 servers recommended for redundancy and load.
• Bandwidth: 1 Gbps network (~125 MB/s) sufficient for typical JSON payloads under 1 KB at 1000 QPS.
• Storage: depends on data retention; for 1 million users, expect tens to hundreds of GBs of data monthly.

Interview Tip

Start by clarifying API usage patterns and expected traffic. Identify the main components: API servers, database, caching, and network. Discuss bottlenecks in order: database first, then servers, then network. Propose scaling solutions step-by-step with reasons. Mention trade-offs like consistency vs availability. Keep answers structured and focused.

Self Check

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

Answer: Add read replicas to distribute read queries and reduce load on the primary database. Also, implement caching to reduce database hits. This addresses the database bottleneck before scaling API servers.

Key Result

The database is the first bottleneck as traffic grows; scaling it with read replicas, caching, and sharding is key before horizontally scaling API servers and adding CDN or microservices.

Practice

1. Which HTTP method is typically used to retrieve data from a REST API without modifying it?

easy

A. DELETE

B. POST

C. GET

D. PUT

Solution

1. Step 1: Understand HTTP methods in REST

   GET is used to request data without changing the server state.

2. Step 2: Match method to action

   POST creates or modifies data, PUT updates, DELETE removes data.

3. Final Answer:

   GET -> Option C

4. Quick Check:

   Retrieve data = GET [OK]

Hint: GET is for reading data only, no changes [OK]

Common Mistakes:

• Confusing POST with GET
• Using PUT for data retrieval
• Thinking DELETE retrieves data

2. Which of the following is the correct URL format to access a specific user with ID 123 in a REST API?

easy

A. /users/123

B. /users/getUser?id=123

C. /getUser/123

D. /users?id=123

Solution

1. Step 1: Identify RESTful URL design

   REST URLs use resource names and IDs as path segments, not actions or query for specific resource.

2. Step 2: Compare options

   /users/123 correctly points to user resource with ID 123; others use verbs or query parameters incorrectly.

3. Final Answer:

   /users/123 -> Option A

4. Quick Check:

   Resource ID in path = /users/123 [OK]

Hint: Use resource path + ID, avoid verbs in URL [OK]

Common Mistakes:

• Using verbs like getUser in URL
• Using query params for resource ID
• Mixing action names with resource paths

3. Given the following REST API call: DELETE /orders/456, what is the expected outcome?

medium

A. It deletes order 456 from the system

B. It updates order 456's status

C. It retrieves order 456's details

D. It creates a new order with ID 456

Solution

1. Step 1: Understand HTTP DELETE method

   DELETE is used to remove a resource identified by the URL.

2. Step 2: Analyze the URL and method

   /orders/456 points to order with ID 456; DELETE removes it.

3. Final Answer:

   It deletes order 456 from the system -> Option A

4. Quick Check:

   DELETE + resource ID = delete resource [OK]

Hint: DELETE method removes resource at given URL [OK]

Common Mistakes:

• Thinking DELETE retrieves data
• Confusing DELETE with POST
• Assuming DELETE creates or updates

4. A developer designed a REST API endpoint as POST /users/123/updateEmail to update a user's email. What is the main issue with this design?

medium

A. Using POST instead of GET for update

B. Including action 'updateEmail' in the URL violates REST principles

C. Missing user ID in the URL

D. Using query parameters instead of path variables

Solution

1. Step 1: Review REST URL design principles

   REST APIs should use resource paths, not actions in URLs.

2. Step 2: Identify the problem in the URL

   Including 'updateEmail' is an action, which breaks REST design; updates should use PUT or PATCH on /users/123.

3. Final Answer:

   Including action 'updateEmail' in the URL violates REST principles -> Option B

4. Quick Check:

   URLs represent resources, not actions [OK]

Hint: Avoid verbs in URLs; use HTTP methods for actions [OK]

Common Mistakes:

• Using verbs in URL paths
• Confusing POST with GET for updates
• Omitting resource IDs

5. You need to design a REST API for a system managing books and their authors. Which design best follows REST principles for retrieving all books by a specific author with ID 789?

hard

A. /books/authors/789

B. /books?author=789

C. /getBooksByAuthor/789

D. /authors/789/books

Solution

1. Step 1: Understand resource hierarchy in REST

   Authors and books are resources; books by an author are a sub-resource of author.

2. Step 2: Evaluate URL options

   /authors/789/books clearly shows books belonging to author 789, following REST resource nesting.

3. Step 3: Consider query vs path

   While query parameters can filter, nested resource path is more RESTful for related resources.

4. Final Answer:

   /authors/789/books -> Option D

5. Quick Check:

   Nested resource path shows relationship [OK]

Hint: Use nested paths for related resources [OK]

Common Mistakes:

• Using verbs in URL
• Overusing query parameters
• Ignoring resource relationships