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
▶
Request Trace
Step 1/5
Forward Proxy

Receives client request and masks client IP

Forwards request to Reverse Proxy over HTTPS

Protocol:HTTP/HTTPS
BeforeClient request originates with original client IP visible
AfterRequest sent with Forward Proxy IP, client IP hidden from server
Reverse Proxy

Accepts request from Forward Proxy and hides backend servers

Routes request to TLS Termination Module

Protocol:HTTP/HTTPS
BeforeRequest arrives with Forward Proxy IP, backend servers unknown
AfterRequest forwarded internally, backend server details hidden from client
TLS Termination Module

Decrypts TLS traffic to inspect HTTP content

Sends decrypted HTTP request to Logging Service

Protocol:Decrypted HTTP
BeforeRequest encrypted in TLS, opaque to internal services
AfterRequest decrypted, HTTP content visible for logging and routing
Logging Service

Logs request metadata including timestamps and headers

Forwards log data to Health Check & Metrics Collector

Protocol:Log Data
BeforeRequest metadata not yet recorded
AfterRequest metadata durably logged for audit and debugging
Health Check & Metrics Collector

Collects logs and metrics to monitor system health

Updates dashboards and triggers alerts if needed

Protocol:Internal Metrics
BeforeNo new metrics for this request processed
AfterSystem health updated with latest request metrics
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ Forward Proxy │
└───────┬───────┘
        │ HTTP/HTTPS
        ▼
┌───────────────┐
│ Reverse Proxy │
└───────┬───────┘
        │ HTTP/HTTPS
        ▼
┌───────────────────────┐
│ TLS Termination Mod   │
└───────┬───────────────┘
        │ Decrypted HTTP
        ▼
┌───────────────┐
│ Logging Svc   │
└───────┬───────┘
        │ Log Data
        ▼
┌───────────────────────────────┐
│ Health Check & Metrics Collctr│
└───────────────────────────────┘
Design Rationale

This architecture illustrates the distinct roles of Forward and Reverse Proxies in request flow. The Forward Proxy acts on the client side, masking the client's IP and filtering outbound requests, thus hiding client details from the server. The Reverse Proxy operates on the server side, concealing backend server identities and balancing load. TLS Termination decrypts incoming encrypted traffic, enabling inspection and logging. The Logging Service captures request metadata for auditing, while the Health Check & Metrics Collector monitors system health and performance. This layered approach ensures security, privacy, and observability by hiding sensitive details at different points and enabling controlled inspection.

Primary Focus

✓

Practice

(1/5)
1. In a chat system request flow, at Step 4 the Delivery Worker checks the recipient's online status cache. What happens if the cache entry is expired at this step?
easy
A. Delivery Worker falls back to persistent message queue for offline delivery
B. Delivery Worker immediately marks message as delivered
C. Delivery Worker drops the message assuming recipient is offline
D. Delivery Worker retries checking cache indefinitely

Solution

  1. Step 1: Understand Delivery Worker role at Step 4

    It checks recipient online status cache to decide delivery method.

  2. Step 2: Behavior on expired cache entry

    Expired cache means unknown status; system falls back to persistent queue to ensure message is not lost.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired cache triggers fallback to persistent queue [check]
Hint: Expired cache triggers fallback, not message drop or infinite retry [check]
Common Mistakes:
2. In the Kafka consumer flow, at step 4 the consumer commits offsets after processing messages. What happens if the consumer crashes before committing the offset?
easy
A. The messages are reprocessed after restart, causing potential duplicates
B. The messages are lost and never reprocessed
C. Kafka automatically commits offsets on behalf of the consumer
D. The consumer group coordinator reassigns partitions immediately

Solution

  1. Step 1: Trace offset commit role at Step 4

    Offset commit marks messages as processed; if not committed, Kafka considers them unprocessed.

  2. Step 2: Understand crash impact

    If consumer crashes before commit, on restart it reprocesses messages from last committed offset, causing duplicates.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Uncommitted offsets cause message reprocessing [check]
Hint: Uncommitted offset -> message replay on restart [OK]
Common Mistakes:
3. If the Kafka cluster responsible for photo upload event streaming goes down, what exactly breaks in the system?
medium
A. Photo uploads fail immediately with HTTP 500 errors to users
B. Feed generation continues normally but stories fail to update
C. Photo metadata extraction and thumbnail generation stop; uploads succeed but processing is delayed indefinitely
D. User notifications about new photos are lost but photos appear in feed

Solution

  1. Step 1: Understand Kafka's role in event streaming

    Kafka streams photo upload events to downstream processors like metadata extraction and feed generation.

  2. Step 2: Trace failure impact

    If Kafka is down, photo uploads still succeed because upload service writes to storage directly. Feed generation depends on Kafka events for stories update; without Kafka, stories updates stop, but feed generation for photos continues from DB. Metadata extraction is delayed but not necessarily indefinite. Notifications are handled separately.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka outage stops stories update but feed photo generation continues [check]
Hint: Kafka outage blocks stories update, feed photos still served [check]
Common Mistakes:
4. You must choose between ULID and KSUID for a global distributed system requiring IDs sortable by generation time and compact encoding. Which is the better choice and why?
medium
A. Use KSUID because it encodes a 32-bit timestamp allowing for a larger time range and smaller encoded size
B. Use KSUID because it uses UUIDv4 internally ensuring uniqueness
C. Use ULID because it uses base32 encoding which is more compact than KSUID's base62
D. Use ULID because it has a longer timestamp and better collision resistance

Solution

  1. Step 1: Compare ULID and KSUID timestamp and encoding

    ULID uses 48-bit timestamp; KSUID uses 32-bit timestamp but encodes IDs in base62, making KSUIDs more compact and supporting a larger time range.

  2. Step 2: Evaluate encoding and uniqueness claims

    ULID uses base32 (less compact); KSUID does not embed UUIDv4 (D is false); ULID's timestamp is longer but KSUID's design suits global scale better.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    KSUID's 32-bit timestamp + base62 encoding -> compact, sortable IDs [check]
Hint: KSUID: compact base62 + 32-bit timestamp for global scale [check]
Common Mistakes:
5. At 10x traffic scale, which component of a global server load balancing system is most likely to fail first and why?
hard
A. The data center ingress routers, since network bandwidth scales linearly and saturates quickly
B. The health monitoring system, due to increased frequency of health checks overwhelming it
C. The GSLB control plane, as it struggles to process and update routing decisions for all data centers in real-time
D. The DNS servers, because they cannot handle the surge in query volume and caching limits failover speed

Solution

  1. Step 1: Analyze scaling challenges

    Health monitoring (The health monitoring system, due to increased frequency of health checks overwhelming it) scales with checks but can be optimized; control plane (The GSLB control plane, as it struggles to process and update routing decisions for all data centers in real-time) is distributed and designed for scale; ingress routers (The data center ingress routers, since network bandwidth scales linearly and saturates quickly) scale with network upgrades.

  2. Step 2: Identify DNS bottleneck

    DNS servers face query volume spikes and caching TTLs limit failover responsiveness, making them the first to fail under 10x load.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    DNS query volume and caching limits cause first failure at scale [check]
Hint: DNS query volume overloads servers 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