Bird
Raised Fist0

Forward Proxy vs Reverse Proxy - What Each Hides and Why It Matters

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Forward Proxy vs Reverse Proxy - What Each Hides and Why It Matters
45 min · senior
senior

You are designing proxy infrastructure for a 50M DAU startup that handles sensitive user data and requires strict encryption, low latency (P99 < 200ms), and offline delivery capabilities. The system must clearly separate concerns of client-side and server-side hiding of network details to optimize security, scalability, and user experience.

Constraints
  • All traffic must be encrypted end-to-end (TLS termination considerations)
  • Offline delivery support for clients with intermittent connectivity
  • P99 latency for proxy request handling must be under 200ms
  • Proxy infrastructure must scale to handle 50M DAU with peak QPS of 1M
  • Clear separation of concerns between forward and reverse proxy roles
📋
Guided Steps
1/5
Step 1
Define the Role and Scope of Forward Proxy
What is the primary function of a forward proxy in this system, and what network details does it hide from the server?
💡 Hint
Think about client-side anonymity and outbound request control.
Key Decision
Use NGINX as a forward proxy to handle client outbound requests, hiding client IPs and enforcing outbound TLS policies.
Interviewer Expectation
Mid: Names NGINX or Squid as forward proxy. Senior: Explains how forward proxy hides client IP and enforces outbound encryption, plus rejects VPN due to lack of fine-grained control and observability.
⚠️Common Wrong Answer
Using a reverse proxy as a forward proxy - leads to incorrect assumptions about what network details are hidden and breaks client anonymity.
Step 2
Define the Role and Scope of Reverse Proxy
What is the primary function of a reverse proxy here, and what network details does it hide from the client?
💡 Hint
Consider backend service abstraction and load balancing.
Key Decision
Use Envoy as a reverse proxy to terminate TLS, load balance requests, and hide backend service topology from clients.
Interviewer Expectation
Mid: Names Envoy or HAProxy as reverse proxy. Senior: Explains how reverse proxy hides backend IPs and service details, enabling zero-trust and service mesh integration, rejecting direct client-to-backend connections due to security risks.
⚠️Common Wrong Answer
Using forward proxy for backend load balancing - breaks security model and backend abstraction.
Step 3
Handling Encryption and TLS Termination
Where should TLS termination occur in the proxy chain to meet encryption and latency constraints?
💡 Hint
Consider end-to-end encryption vs. proxy offloading trade-offs.
Key Decision
Terminate TLS at the reverse proxy (Envoy) to offload backend services while maintaining encrypted client-to-proxy channel; forward proxy (NGINX) enforces outbound TLS policies without terminating client TLS.
Interviewer Expectation
Mid: Mentions TLS termination at reverse proxy. Senior: Explains why forward proxy does not terminate TLS to preserve client privacy and how this reduces latency and backend load, rejecting TLS termination at forward proxy due to client IP exposure and breaking end-to-end encryption.
⚠️Common Wrong Answer
Terminating TLS at forward proxy - exposes client IP and breaks end-to-end encryption guarantees.
Step 4
Design for Offline Delivery and Low Latency
How can the proxy infrastructure support offline delivery and maintain P99 latency under 200ms?
💡 Hint
Think about caching layers and asynchronous delivery mechanisms.
Key Decision
Integrate Redis as a caching layer at the forward proxy to buffer requests for offline clients and use Kafka for asynchronous delivery retries, ensuring P99 latency under 200ms by offloading slow backend calls.
Interviewer Expectation
Mid: Suggests caching to improve latency. Senior: Details Redis TTL-based cache invalidation and offline detection, plus Kafka partitioning for ordered retries, rejecting synchronous backend calls that increase latency.
⚠️Common Wrong Answer
No caching or retry mechanism - leads to high latency and poor offline support.
Step 5
API Design for Proxy Interaction
What are 3 core API endpoints that the forward and reverse proxies should expose or handle to support client requests, backend routing, and proxy health?
💡 Hint
Consider request forwarding, status checks, and acknowledgments.
Key Decision
Define endpoints: (1) POST /forward-proxy/request for client outbound requests, (2) GET /reverse-proxy/route for backend service routing, (3) GET /proxy/health for health checks; implemented with REST over HTTPS using Envoy and NGINX modules.
Interviewer Expectation
Mid: Lists basic endpoints. Senior: Explains endpoint roles in request lifecycle, security implications, monitoring integration, and observability, rejecting generic endpoints without security or observability considerations.
⚠️Common Wrong Answer
Omitting health or acknowledgment endpoints - leads to poor observability and unreliable proxy operation.
🔌
API Design Challenge
Sketch 3 core API endpoints that a forward proxy and a reverse proxy would expose or handle in this system. Consider client requests, server responses, and proxy management.
Hints
  • How does the client send requests through the forward proxy?
  • How does the reverse proxy route requests to backend services?
  • How does the system handle proxy health checks or client acknowledgments?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Clear distinction between forward and reverse proxy roles with real tech
  • Explanation of what network details each proxy hides and why
  • TLS termination strategy aligned with encryption and latency constraints
  • Caching and asynchronous delivery design for offline support
  • API design covering client requests, backend routing, and health checks
Good to Have - 30%
  • Use of Redis TTL for cache invalidation and offline detection
  • Kafka partitioning strategy for ordered message delivery
  • Discussion of security implications of proxy placement
  • Consideration of scalability to 50M DAU and 1M QPS
Bonus - 10%
  • Integration with service mesh for reverse proxy
  • Detailed failure mode analysis for proxy outages
  • Observability and monitoring design for proxies
Anti-patterns to Avoid
Terminating TLS at forward proxy - breaks client privacy and end-to-end encryption, exposing client IP and increasing attack surface
Using forward proxy as backend load balancer - violates proxy role separation and security, exposing backend topology
No caching or retry mechanism - causes high latency and poor offline experience, leading to user dissatisfaction
Omitting health check endpoints - leads to undetected proxy failures and degraded availability, reducing system reliability
Using VPN instead of forward proxy - lacks fine-grained control and observability, increasing security risks
Direct client-to-backend connections - exposes backend topology and increases attack surface, compromising security
✅
Model Answer
▼ Reveal

The system uses NGINX as a forward proxy to hide client IPs and enforce outbound TLS policies, while Envoy serves as a reverse proxy to terminate TLS, load balance requests, and hide backend service topology. TLS termination occurs only at the reverse proxy to maintain end-to-end encryption and reduce latency. Redis caching at the forward proxy buffers requests for offline clients, and Kafka handles asynchronous delivery retries to support offline delivery. The proxies expose REST API endpoints for request forwarding, backend routing, and health monitoring to ensure observability and reliability.

Key Decisions
  • Use NGINX as forward proxy to hide client IP and enforce outbound TLS policies
  • Use Envoy as reverse proxy to terminate TLS and load balance backend services
  • Terminate TLS only at reverse proxy to preserve client privacy and reduce backend load
  • Implement Redis caching with TTL for offline delivery support and latency reduction
  • Use Kafka with partitioning for ordered asynchronous retries to handle offline clients
  • Design REST APIs with security and observability in mind, including health checks
  • NGINX as forward proxy to hide client IP and enforce outbound TLS policies
  • Envoy as reverse proxy to terminate TLS, load balance, and hide backend topology
  • TLS termination only at reverse proxy to maintain end-to-end encryption and reduce latency
  • Redis caching at forward proxy for offline delivery buffering and low latency
  • Kafka for asynchronous message delivery and retry handling to support offline clients
  • REST API endpoints for request forwarding, backend routing, and proxy health monitoring
  • Reject VPN as forward proxy due to lack of granular control and observability
  • Reject direct client-to-backend connections to maintain security and abstraction

Practice

(1/5)
1. In a cache stampede prevention system, at Step 4 the Cache Rebuilder checks if a distributed lock is held before regenerating the cache. What happens if the lock is already held by another process?
easy
A. The Cache Rebuilder immediately regenerates the cache anyway, risking duplicate work
B. The Cache Rebuilder waits or returns stale data until the lock is released
C. The Cache Rebuilder deletes the cache key to force a fresh fetch next time
D. The Cache Rebuilder escalates the request to the backend synchronously

Solution

  1. Step 1: Trace Cache Rebuilder behavior at Step 4

    If the distributed lock is held, another process is regenerating the cache.

  2. Step 2: Understand correct handling

    The Cache Rebuilder waits or serves stale data to avoid duplicate regeneration and backend overload.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Waiting or serving stale data prevents duplicate cache rebuilds [check]
Hint: Lock held -> wait or serve stale, no duplicate rebuilds [OK]
Common Mistakes:
2. In the flash sale system request flow, at Step 4 the Inventory Service checks stock availability before confirming the order. What happens if the stock is insufficient at this step?
easy
A. The Inventory Service immediately rejects the order and sends a failure response
B. The Inventory Service queues the request for later retry without notifying the user
C. The Inventory Service reserves partial stock and waits for replenishment
D. The Inventory Service forwards the request to the Payment Service anyway

Solution

  1. Step 1: Trace Inventory Service behavior at Step 4

    Inventory Service performs a synchronous stock check; if stock is insufficient, it rejects the order immediately to prevent overselling.

  2. Step 2: Evaluate other options

    Queuing for retry (A) delays user feedback and risks overselling. Partial reservation (C) is inconsistent with flash sale atomicity. Forwarding to Payment (D) without stock confirmation breaks order integrity.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Inventory rejects insufficient stock immediately [check]
Hint: Inventory rejects insufficient stock immediately [check]
Common Mistakes:
3. In the photo feed generation flow, at step 4 the Feed Worker fetches stories from the Stories Service cache. What happens if the cache TTL for a user's stories has expired at this step?
easy
A. The Feed Worker asynchronously refreshes the cache but returns an empty stories section immediately
B. The Feed Worker triggers a synchronous fetch from the Stories DB and blocks until fresh stories are retrieved
C. The Feed Worker returns stale stories from a backup cache without fetching fresh data
D. The Feed Worker skips stories for that user and proceeds with only photo posts in the feed

Solution

  1. Step 1: Trace Feed Worker behavior at cache miss

    When TTL expires, the cache is stale. The Feed Worker must avoid blocking feed generation.

  2. Step 2: Understand asynchronous cache refresh

    To maintain low latency, the Feed Worker returns empty stories immediately and triggers async cache refresh. Blocking fetch (B) would increase latency. Returning stale data (A) risks outdated content. Skipping stories silently (C) loses user experience.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Async cache refresh avoids blocking feed generation [check]
Hint: Async cache refresh avoids blocking feed generation [OK]
Common Mistakes:
4. A system needs to estimate the number of unique users visiting a website daily, with minimal memory usage and acceptable error margin. Which component is best suited to handle this requirement?
easy
A. A Redis cache storing all user IDs explicitly
B. A relational database with unique user ID indexing
C. A HyperLogLog data structure for cardinality estimation
D. A Bloom filter to check if a user has visited before

Solution

  1. Step 1: Understand memory constraints and error tolerance

    Storing all user IDs explicitly (Redis or relational DB) is memory-heavy and not scalable for large user bases.

  2. Step 2: Identify HyperLogLog's role

    HyperLogLog provides approximate unique counts with fixed small memory and tunable error, ideal for large-scale cardinality estimation.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    HyperLogLog trades accuracy for memory efficiency [check]
Hint: Approximate unique counts with tiny memory -> HyperLogLog [check]
Common Mistakes:
5. At 10x scale, which Elasticsearch component is most likely to become the bottleneck first, and why?
hard
A. Ingest Nodes, because preprocessing pipelines cannot keep up with write throughput
B. Master Node, because cluster state updates grow exponentially with shard count
C. Data Nodes, because shard replication traffic saturates network bandwidth
D. Coordinating Node, because it must merge results from an increasing number of shards

Solution

  1. Step 1: Analyze scaling impact on Coordinating Node

    Coordinating Nodes merge and sort results from all shards; with 10x shards, merging overhead grows significantly.

  2. Step 2: Compare other components

    Master Node scales with cluster state but less impacted than query merging; Data Nodes handle replication but network can be scaled; Ingest Nodes can be scaled horizontally.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Coordinating Node merging overhead grows fastest at scale [check]
Hint: Coordinating Node merges explode with shard count increase [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