Bird
Raised Fist0

REST API Design Principles - Resources, Methods, Status Codes, Pagination

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
API Gateway

Receives client GET /users?page=2&limit=10 request

Extracts HTTP headers and query params for routing

Protocol:HTTP REST
BeforeClient request just arrived at API Gateway
AfterRequest parsed and forwarded to Rate Limiter
Rate Limiter

Checks client request rate against limits

Allows or rejects request based on token bucket state

Protocol:Internal RPC
BeforeRequest pending rate limit check
AfterRequest passed rate limiting and forwarded to Auth Service
Auth Service

Validates authentication token from request headers

Confirms user identity and permissions

Protocol:Internal RPC
BeforeRequest authenticated status unknown
AfterUser authenticated; request authorized for REST API Service
REST API Svc

Processes GET /users with pagination parameters

Constructs CQL query with LIMIT and OFFSET for Cassandra

Protocol:CQL Query
BeforeRequest authorized, pagination params extracted
AfterQuery sent to Cassandra to fetch requested page of users
Cassandra

Executes CQL query to retrieve user data page

Returns paginated user resource list to REST API Service

Protocol:CQL Response
BeforeQuery received with pagination constraints
AfterUser data page returned to REST API Service
REST API Svc

Formats response with HTTP 200 and pagination metadata

Includes Link headers for next/prev pages

Protocol:Internal RPC
BeforeUser data received from Cassandra
AfterResponse ready to send back to API Gateway
API Gateway

Sends HTTP 200 response with user data and pagination info

Completes client request lifecycle

Protocol:HTTP REST
BeforeResponse received from REST API Service
AfterClient receives paginated user resource list
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ API Gateway   │
└───────┬───────┘
        │ HTTP REST
        ▼
┌───────────────┐
│ Rate Limiter  │
└───────┬───────┘
        │ Internal RPC
        ▼
┌───────────────┐
│ Auth Service  │
└───────┬───────┘
        │ Internal RPC
        ▼
┌───────────────┐
│ REST API Svc  │
└───────┬───────┘
        │ CQL Query
        ▼
┌───────────────┐
│ Cassandra     │
└───────────────┘
Design Rationale

This architecture diagram illustrates a REST API request flow emphasizing design principles like resource-based URLs, HTTP methods, status codes, and pagination. The API Gateway acts as the client entry point, forwarding requests to the Rate Limiter which enforces usage policies. Auth Service validates user credentials before the REST API Service processes the request. Pagination parameters are translated into Cassandra CQL queries with LIMIT and OFFSET to efficiently fetch resource subsets. The REST API Service formats responses with appropriate HTTP status codes and pagination metadata, including Link headers for navigation. This vertical flow ensures modular responsibility separation, scalability, and adherence to RESTful best practices.

Primary Focus

✓

Practice

(1/5)
1. In the Pastebin system request flow, at Step 4 the Expiration Worker scans stored snippets to remove expired entries. What state does the worker observe for a snippet whose TTL just expired but is still being accessed by a user?
easy
A. The snippet is immediately deleted and inaccessible to the user
B. The snippet remains accessible until the worker completes the deletion batch
C. The snippet is marked as expired but still served until a manual cleanup
D. The snippet is locked and user requests are blocked until deletion finishes

Solution

  1. Step 1: Trace Expiration Worker behavior at Step 4

    The worker deletes expired snippets in batches; deletion is not instantaneous upon TTL expiry.

  2. Step 2: Understand user access during deletion

    Until deletion completes, the snippet remains accessible; no locking or blocking occurs.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Batch deletion delays snippet removal, keeping it accessible briefly [check]
Hint: Expiration deletion is batch-based, not instant [check]
Common Mistakes:
2. A web service receives highly variable traffic with some clients opening many simultaneous connections, while others open few. Which load balancing algorithm best distributes load evenly across servers?
easy
A. Round Robin, because it cycles through servers regardless of connection count
B. Weighted Round Robin, because it assigns requests based on server weights only
C. IP Hash, because it ensures requests from the same client always go to the same server
D. Least Connections, because it directs new requests to the server with the fewest active connections

Solution

  1. Step 1: Understand traffic variability

    Clients open varying numbers of connections, so servers can become unevenly loaded if requests are assigned blindly.

  2. Step 2: Evaluate load balancing algorithms

    Round Robin ignores current load, IP Hash pins clients to servers (may cause imbalance), Weighted Round Robin uses static weights ignoring dynamic load. Least Connections dynamically balances based on active connections.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Least Connections adapts to real-time load, balancing uneven client connections [check]
Hint: Least Connections adapts to active load, not just request count [check]
Common Mistakes:
3. If the Kafka broker cluster goes down unexpectedly, what exactly breaks in the message delivery pipeline?
medium
A. Producers receive errors and messages are lost if not retried; consumers stop receiving new messages causing delivery stalls
B. Consumers continue reading cached messages but new messages from producers are lost until broker recovers
C. Producers block indefinitely waiting to write messages, causing backpressure
D. Messages are duplicated because brokers resend uncommitted messages after restart

Solution

  1. Step 1: Trace producer behavior on broker failure

    Producers get errors on send; without retries, messages are lost. They do not block indefinitely (A).

  2. Step 2: Trace consumer behavior

    Consumers cannot fetch new messages; cached messages may be consumed but no new delivery occurs, causing stalls. Duplication (D) is prevented by offset commits.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Broker failure causes producer errors and consumer stalls, risking message loss [check]
Hint: Broker down -> producer errors, consumer stalls, possible message loss [check]
Common Mistakes:
4. At 10x scale, which component in the route leak mitigation system is most likely to fail first, and why?
hard
A. The route validation workers, as CPU-intensive prefix checks saturate compute resources
B. The edge routers, because BGP session limits prevent scaling to more peers
C. The centralized configuration database, due to write contention and latency spikes
D. The monitoring dashboards, overwhelmed by alert volume causing UI crashes

Solution

  1. Step 1: Identify route validation worker bottleneck

    CPU-intensive prefix checks saturate compute resources first as scale increases.

  2. Step 2: Compare other components

    Config DB (A) can be sharded; edge routers (B) have limits but can be upgraded; dashboards (C) are less critical.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    CPU saturation in validation workers is first bottleneck at scale [check]
Hint: CPU-bound validation workers fail before others [check]
Common Mistakes:
5. At 10x current scale, which component in the YouTube view count system is most likely to fail first, and why?
hard
A. The CDN edge caches because they cannot handle the increased video delivery requests
B. The view count database because it is a centralized bottleneck for high write throughput
C. The transcoding pipeline because it cannot process 10x more video uploads in time
D. The upload service because it cannot handle 10x concurrent upload connections

Solution

  1. Step 1: Analyze component scalability at 10x load

    CDN edge caches (A) scale horizontally and are designed for massive read throughput. Transcoding pipeline (C) can be scaled with more workers. Upload service (D) can be scaled with load balancers and stateless servers.

  2. Step 2: Identify view count database bottleneck

    View count DB is a centralized write hotspot with high contention and latency sensitivity. At 10x scale, it becomes the first bottleneck due to write amplification and consistency requirements.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Centralized view count DB write bottleneck fails first [check]
Hint: Centralized DB write bottleneck breaks first at scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard