Bird
Raised Fist0

Load Balancer vs API Gateway vs Reverse Proxy - Key Differences

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

Sends HTTP request

Client initiates HTTPS request to system

Protocol:HTTPS
BeforeClient has user input ready to send
AfterRequest is sent over HTTPS to Load Balancer
Load Balancer

Distributes request

Load Balancer selects an API Gateway instance based on load

Protocol:HTTPS
BeforeLoad Balancer receives incoming HTTPS request
AfterRequest forwarded to selected API Gateway instance
API Gateway

Processes request

API Gateway authenticates, applies rate limits, and routes request

Protocol:HTTPS
BeforeAPI Gateway receives forwarded HTTPS request
AfterRequest validated and routed to Reverse Proxy
Reverse Proxy

Handles SSL termination and caching

Reverse Proxy decrypts SSL, serves cached content if available

Protocol:HTTP
BeforeReverse Proxy receives HTTPS request from API Gateway
AfterRequest decrypted and forwarded to Backend Services
Backend Services

Processes business logic

Backend Services execute application logic and query databases

Protocol:Internal HTTP/DB protocol
BeforeBackend Services receive decrypted request
AfterBackend Services generate response after DB queries
Databases / Storage

Responds to queries

Databases return requested data to Backend Services

Protocol:SQL/NoSQL query
BeforeDatabases receive query from Backend Services
AfterDatabases send data back to Backend Services
🏗️
Architecture Diagram
Architecture Diagram
┌─────────┐
│ Client  │
└────┬────┘
     │ HTTP Request (HTTPS)
     ▼
┌───────────────┐
│ Load Balancer │
│ (Distributes  │
│ traffic to    │
│ multiple API  │
│ Gateways)     │
└────┬──────────┘
     │ HTTP Request (HTTPS)
     ▼
┌───────────────┐
│ API Gateway   │
│ (Auth, Rate   │
│ limiting,     │
│ routing)      │
└────┬──────────┘
     │ HTTP Request (HTTPS)
     ▼
┌───────────────┐
│ Reverse Proxy │
│ (SSL Term,    │
│ caching,      │
│ compression)  │
└────┬──────────┘
     │ HTTP Request (HTTP)
     ▼
┌───────────────┐
│ Backend       │
│ Services      │
└────┬──────────┘
     │ DB Queries (SQL/NoSQL)
     ▼
┌───────────────┐
│ Databases /   │
│ Storage       │
└───────────────┘

This architecture illustrates the distinct roles of Load Balancer, API Gateway, and Reverse Proxy in handling client requests. The Load Balancer distributes incoming traffic across multiple API Gateway instances to ensure scalability and availability. The API Gateway enforces security policies like authentication and rate limiting, and routes requests appropriately. The Reverse Proxy manages SSL termination, caching, and compression to optimize backend communication. Backend Services process business logic and interact with Databases for persistent storage. This vertical flow clarifies how each component adds a layer of responsibility, improving system modularity and performance.

Primary Focus

✓

Practice

(1/5)
1. In the webhook delivery system, at Step 4 the Delivery Worker checks the subscriber's last acknowledged event ID before sending the next event. What state does the Delivery Worker hold if the subscriber's acknowledgement is delayed beyond the retry timeout?
easy
A. Immediately escalates the failure to the alerting system
B. Keeps the event in 'pending retry' state and schedules a retry
C. Deletes the event from the queue assuming subscriber is unreachable
D. Marks the event as delivered and moves on to the next event

Solution

  1. Step 1: Trace Delivery Worker decision at Step 4 -- subscriber ack delay

    The worker waits for acknowledgement; if delayed beyond retry timeout, it escalates failure to alerting for manual intervention.
  2. Step 2: Eliminate other options

    Marking as delivered without ack breaks reliability; deleting event loses data; scheduling retry is normal but after multiple failures escalation is needed.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    Delayed ack beyond retry timeout -> escalate alert [check]
Hint: Delayed ack triggers alert escalation [check]
Common Mistakes:
2. In a relational database transaction flow, at Step 4 the transaction manager checks the lock table before committing. What happens if the lock is held by another transaction at this step?
easy
A. The transaction manager immediately aborts the transaction without retry
B. The transaction manager waits (blocks) until the lock is released or a timeout occurs
C. The transaction manager skips the lock check and commits anyway
D. The transaction manager escalates the lock to a global lock manager

Solution

  1. Step 1: Understand lock table role at Step 4

    The transaction manager uses the lock table to ensure no conflicting writes before commit.
  2. Step 2: Behavior on lock contention

    If the lock is held, the transaction manager blocks to maintain serializability, waiting or timing out rather than aborting immediately or skipping checks.
  3. Final Answer:

    Option B -> Option B
  4. Quick Check:

    Lock contention causes blocking until release or timeout [check]
Hint: Lock held -> transaction blocks, no skipping or immediate abort [check]
Common Mistakes:
3. At 10x transaction volume, which component of a relational database system is most likely to become the bottleneck first, and why?
hard
A. The storage engine, because disk I/O bandwidth saturates quickly
B. The query optimizer, because it cannot generate execution plans fast enough
C. The lock manager, due to increased contention causing transaction delays
D. The network layer, as increased client connections overwhelm bandwidth

Solution

  1. Step 1: Identify bottleneck under high concurrency

    Lock manager handles concurrency control; at 10x load, lock contention increases exponentially.
  2. Step 2: Compare other components

    Query optimizer scales well with caching; storage and network scale with hardware upgrades; lock manager contention is harder to mitigate.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    Lock manager contention -> first bottleneck at high transaction scale [check]
Hint: Lock manager contention grows fastest at scale [check]
Common Mistakes:
4. At 10x scale, which component in the real-time ML inference system is most likely to fail first and why?
hard
A. Model storage backend, due to increased read latency from large model files
B. Load balancer, since it cannot efficiently distribute traffic to a rapidly scaling number of servers
C. Kafka event stream, as partition count limits throughput and causes lag under heavy update load
D. Prediction API servers, because CPU-intensive model inference cannot be parallelized easily

Solution

  1. Step 1: Analyze scaling bottlenecks

    Model storage (A) scales with caching; Kafka (C) can be scaled by adding partitions; load balancers (D) scale horizontally.
  2. Step 2: Identify CPU bottleneck in inference

    Prediction API servers (B) perform CPU/GPU-bound inference; scaling is limited by hardware and model complexity, causing first failure under 10x load.
  3. Final Answer:

    Option D -> Option D
  4. Quick Check:

    Inference servers hit CPU/GPU limits before storage or Kafka scale [check]
Hint: Inference servers hit CPU/GPU bottleneck before other components [OK]
Common Mistakes:
5. At 10x scale, which component in a server-side service discovery architecture is most likely to fail first and why?
hard
A. Service registry, due to centralized state and high query volume causing latency spikes
B. Individual microservices, as they cannot handle increased load without horizontal scaling
C. API Gateway, because it cannot cache service endpoints and must query registry on every request
D. Load balancers, since they become overwhelmed by the increased number of service instances

Solution

  1. Step 1: Identify bottlenecks in server-side discovery

    API Gateway queries registry per request without caching, causing query amplification at scale.
  2. Step 2: Compare other components

    Registry is centralized but can be scaled with sharding; microservices scale horizontally; load balancers handle instance scaling better than API Gateway query load.
  3. Final Answer:

    Option C -> Option C
  4. Quick Check:

    API Gateway query volume grows linearly causing first failure [check]
Hint: API Gateway query volume grows fastest causing first failure [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