Bird
Raised Fist0

GraphQL vs REST - Trade-offs for Different Query Patterns

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/8
Client

Sends GraphQL query or REST request

Client initiates a complex GraphQL query or simple REST GET

Protocol:HTTP
BeforeClient has user input ready to send
AfterRequest is in transit to API Gateway
API Gateway

Receives and routes request

API Gateway identifies request type and forwards accordingly

Protocol:HTTP
BeforeRequest just arrived at API Gateway
AfterRequest forwarded to Authentication Service (REST) or Backend Services (GraphQL)
Authentication Service

Validates authentication token

Checks token validity for REST requests before backend processing

Protocol:HTTP
BeforeREST request pending authentication
AfterToken validated; request authorized for backend
Backend Services

Processes request and checks cache

Backend Services parse GraphQL query or REST resource and query Cache Layer

Protocol:Redis GET
BeforeRequest authorized and ready for data retrieval
AfterCache hit or miss determined; data fetched or requested from Database(s)
Cache Layer

Returns cached data or misses

Cache Layer returns data if present or signals miss

Protocol:Redis GET
BeforeCache queried for requested data
AfterCache hit returns data; cache miss triggers DB query
Database(s)

Executes query and returns data

Database executes complex GraphQL or simple REST query

Protocol:SQL/NoSQL Query
BeforeCache miss or data not in cache
AfterData returned to Backend Services for response assembly
Backend Services

Assembles response

Backend Services format data per GraphQL or REST response schema

Protocol:HTTP
BeforeData received from Cache Layer or Database(s)
AfterResponse ready to send back to API Gateway
API Gateway

Sends response to client

API Gateway returns final response to client

Protocol:HTTP
BeforeResponse ready at API Gateway
AfterClient receives response data
🏗️
Architecture Diagram
Architecture Diagram
      ┌─────────┐
      │ Client  │
      └────┬────┘
           │ HTTP Request (GraphQL or REST)
           ▼
      ┌───────────────┐
      │ API Gateway   │
      └────┬────┬─────┘
           │    │
           │    │ REST Request
           │    ▼
           │  ┌────────────────────┐
           │  │ Auth Service       │
           │  └────┬───────────────┘
           │       │ Auth Token Validated
           │       ▼
           │  ┌───────────────┐
           │  │ Backend Svcs  │
           │  └────┬────┬─────┘
           │       │    │
           │       │    │ Cache Lookup (Redis GET)
           │       │    ▼
           │       │  ┌───────────────┐
           │       │  │ Cache Layer   │
           │       │  └────┬──────────┘
           │       │       │ Cache Miss or Hit
           │       │       ▼
           │       │  ┌───────────────┐
           │       │  │ Database(s)   │
           │       │  └───────────────┘
           │       │
           ▼       ▼
      Response  Response
      (GraphQL) (REST)
Design Rationale

This architecture contrasts GraphQL and REST query handling through a unified API Gateway. The Client sends either a complex GraphQL query or a simple REST request. The API Gateway routes REST requests through the Authentication Service for token validation, while GraphQL queries proceed directly to Backend Services. Backend Services leverage a Cache Layer to optimize data retrieval, reducing load on Database(s). Cache hits return data quickly; misses trigger database queries. Backend Services then assemble responses tailored to the query type. This design highlights trade-offs: GraphQL enables flexible, nested queries but requires more backend processing, while REST offers simpler, cache-friendly endpoints with explicit authentication steps. The vertical flow clarifies component roles and data movement, emphasizing how caching and authentication differ between query patterns.

Primary Focus

✓

Practice

(1/5)
1. In a consistent hashing ring, at Step 4 the request router receives a key and hashes it to a point on the ring. What happens next?
easy
A. The router assigns the key to the first node clockwise from the key's hash point
B. The router assigns the key to the node with the closest lower hash value
C. The router rehashes the key until it finds a node with available capacity
D. The router broadcasts the key to all nodes and waits for a response

Solution

  1. Step 1: Trace key assignment in consistent hashing

    Consistent hashing assigns keys to the first node clockwise from the key's hash on the ring.

  2. Step 2: Eliminate incorrect options

    Lower hash value assignment breaks ring semantics; rehashing or broadcasting is inefficient and not part of consistent hashing.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Consistent hashing assigns keys clockwise on the ring [check]
Hint: Keys go clockwise to next node on ring [check]
Common Mistakes:
2. If the Bloom filter's hash functions are not independent and produce correlated outputs, what is the exact failure mode observed?
medium
A. The bit array will saturate quickly causing excessive false positives and reduced filter effectiveness
B. The filter will have false negatives, incorrectly rejecting existing members
C. The false positive rate increases beyond the expected theoretical rate
D. Insertions will fail silently without updating the bit array

Solution

  1. Step 1: Understand hash function independence role

    Independent hash functions distribute bits uniformly; correlated hashes cause clustering.

  2. Step 2: Trace effect of correlated hashes

    Correlated hashes set overlapping bits, saturating the bit array faster, increasing false positives and reducing filter effectiveness.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Correlated hashes cause bit array saturation, raising false positives [check]
Hint: Correlated hashes cause bit array saturation and false positives [check]
Common Mistakes:
3. If the message queue (e.g., Kafka) between the upload service and transcoding pipeline fails, what exactly breaks in the video processing flow?
medium
A. Uploaded videos are accepted but never reach transcoding, so no processed versions are generated
B. Upload service blocks until transcoding completes, causing upload timeouts
C. Videos are transcoded multiple times causing duplicate outputs
D. View counts increment incorrectly due to missing transcoding metadata

Solution

  1. Step 1: Trace failure impact of message queue outage

    The queue decouples upload and transcoding. Without it, upload service cannot enqueue transcoding jobs. Uploads succeed but transcoding workers receive no tasks, so no processed videos are generated. Blocking upload (B) is incorrect because upload is asynchronous. Duplicate transcoding (A) is unrelated. View count errors (D) happen downstream, not due to queue failure.

  2. Step 2: Confirm exact failure mode

    Uploads accepted but stuck before transcoding is the precise failure.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Queue failure causes transcoding jobs to be lost, no processed videos [check]
Hint: Queue failure means no transcoding jobs dispatched [check]
Common Mistakes:
4. For a system requiring globally unique, roughly time-ordered IDs across multiple data centers, which approach best balances latency and uniqueness guarantees?
medium
A. Use a single centralized ID generator with synchronous replication to all data centers
B. Use decentralized Snowflake-like generators with loosely synchronized clocks and node IDs
C. Generate UUID v4 randomly at each data center without coordination
D. Use database auto-increment IDs partitioned by data center and combine with data center ID

Solution

  1. Step 1: Evaluate centralized generator with sync replication

    This causes high latency and single point of failure, unsuitable for geo-distributed low-latency needs.

  2. Step 2: Assess decentralized Snowflake approach

    Decentralized generators with node IDs and loosely synchronized clocks provide low latency and uniqueness with approximate ordering.

  3. Step 3: Consider UUID v4 and DB auto-increment

    UUID v4 lacks ordering; DB auto-increment with partitioning risks collisions and coordination overhead.

  4. Final Answer:

    Option B -> Option B

  5. Quick Check:

    Decentralized Snowflake -> low latency + uniqueness + approximate ordering [check]
Hint: Decentralized with node ID and clock sync balances latency and uniqueness [check]
Common Mistakes:
5. At 10x scale, which component is most likely to become the first bottleneck in the stock exchange system, and why?
hard
A. The network layer, because TCP connections for order submission exceed server socket limits
B. The Market Data Feed, because broadcasting to millions of subscribers saturates network bandwidth
C. The Order Book storage, because the relational database cannot handle the write throughput
D. The Matching Engine, because partitioned order books require cross-partition coordination for large orders

Solution

  1. Step 1: Analyze scaling challenges

    Matching Engine partitions order books per stock symbol, but large cross-symbol or large orders require coordination, causing latency and bottlenecks at scale.

  2. Step 2: Evaluate other components

    Market Data Feed scales with multicast or sharding; Order Book storage uses scalable Kafka or NoSQL; network layer scales with load balancers and horizontal scaling.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Cross-partition coordination -> Matching Engine bottleneck at scale [check]
Hint: Cross-partition coordination bottlenecks matching engine [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