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
Understanding the distinct roles and privacy boundaries of forward and reverse proxies in network architectures
mediumNetworking and ProtocolsFreq: common
⚙️
Functional Requirements
  • Forward proxy must hide client IP and metadata from destination servers to enable privacy and access control.
  • Reverse proxy must hide backend server details (IP, topology) from clients to enable security and load balancing.
  • Both proxies should support TLS termination and re-encryption to inspect or route traffic securely.
  • Forward proxy should support caching and filtering to reduce bandwidth and enforce policies.
  • Reverse proxy should support load balancing, health checks, and request routing to backend services.
  • Both proxies must log requests for auditing without exposing sensitive internal details.
📊
Non-Functional Requirements
  • Support at least 2 billion daily active users (DAU) generating 40 requests per user per day.
  • Achieve 99.99% availability with failover and redundancy for proxy components.
  • Maintain end-to-end latency under 100ms P99 for proxy request handling.
  • Handle peak write QPS of approximately 925K requests per second (derived in estimation).
  • Ensure security compliance with TLS 1.3 and support for mutual TLS authentication.
❓
Clarifying Questions to Ask
  • What protocols must the proxies support (HTTP/HTTPS, WebSocket, etc.)?
  • Is TLS termination required at the proxy or end-to-end encryption mandatory?
  • What scale of traffic and peak QPS should the proxies handle?
  • Are there specific compliance or logging requirements for auditing?
  • Should the proxies support caching or content filtering?
  • What failure scenarios and recovery mechanisms are expected?
Out of Scope
✗ Designing the backend application servers or origin infrastructure behind reverse proxies.
✗ Detailed implementation of client-side proxy configuration or browser integration.
✗ Intrusion detection or advanced threat protection beyond basic filtering.
✗ Proxy protocol extensions beyond HTTP/HTTPS (e.g., FTP, SMTP).
📌
Assumptions
  • 2 billion DAU
  • 40 requests per user per day
  • Average request size 100 bytes
  • Replication factor 3 for storage durability
⚡
QPS Calculation
write qps2,000,000,000 × 40 / 86,400 ≈ 925,926 requests/sec
peak write qpsAssuming 2× peak factor → 1,851,852 requests/sec
read qpsAssuming read-heavy proxy logs and cache hits, 3× write QPS → 2,777,778 requests/sec
💾
Storage Estimate
daily storage925,926 req/sec × 100 bytes × 86,400 sec ≈ 8 TB/day
retention days30
total storage8 TB × 30 = 240 TB
with replication240 TB × 3 = 720 TB
🖥️
Server Estimate
forward proxy serversAssuming 10 Gbps NICs, each can handle ~10K req/sec → 185 servers
reverse proxy serversWith load balancing and TLS offload, each handles ~15K req/sec → 124 servers
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          |   Clients   |
          +------+------+
                 |
          +------+-------+
          | Forward Proxy|
          +------+-------+
                 |
          +------+-------+
          | Reverse Proxy|
          +------+-------+
                 |
          +------+-------+
          | Backend Srv |
          +-------------+
                 |
          +------+-------+
          |   Logging    |
          +--------------+
🧩
Components
Forward Proxy
Acts on behalf of clients to hide their IP and metadata from destination servers, enabling privacy and policy enforcement.
Why thisEnvoy Proxy supports advanced routing, TLS termination, and caching with high throughput at 1M+ req/sec per node.
Why notSquid Proxy lacks native support for modern TLS 1.3 and scales poorly beyond 100K req/sec without complex sharding.
Reverse Proxy
Acts on behalf of backend servers to hide their IPs and topology from clients, providing load balancing and security.
Why thisNginx Plus offers mature load balancing, health checks, and TLS offload with sub-100ms latency at 15K req/sec per server.
Why notHAProxy requires more manual configuration and does not natively support dynamic service discovery at scale.
TLS Termination Module
Handles TLS handshake and encryption/decryption to enable inspection and routing of encrypted traffic.
Why thisBoringSSL is optimized for Google-scale TLS workloads with low latency and high concurrency.
Why notOpenSSL has higher latency and less efficient concurrency handling under 1M+ connections.
Logging Service
Aggregates proxy logs for auditing, compliance, and debugging without exposing sensitive internal details.
Why thisKafka provides durable, scalable log ingestion with partitioning to handle 3M+ messages/sec.
Why notElasticsearch ingestion directly from proxies risks overload and lacks durable buffering.
Health Check & Metrics Collector
Monitors proxy health and performance metrics to trigger failover and scaling decisions.
Why thisPrometheus supports high-cardinality metrics collection with alerting and integrates with Envoy and Nginx.
Why notNagios lacks native support for high-frequency metrics and dynamic service discovery.
🔄
Data Flow
1
Client → Forward Proxy
Client sends request to forward proxy which masks client IP and applies filtering.
Forward proxy terminates TLS if configured, enabling inspection.
2
Forward Proxy → Reverse Proxy
Forward proxy forwards sanitized request to reverse proxy, hiding client details.
Request is re-encrypted or forwarded in plaintext based on policy.
3
Reverse Proxy → Backend Server
Reverse proxy load balances request to healthy backend server, hiding backend IPs.
Reverse proxy terminates TLS from forward proxy and optionally re-encrypts.
4
Backend Server → Reverse Proxy
Backend server responds to reverse proxy, which forwards response to forward proxy.
Reverse proxy may cache or compress response.
5
Reverse Proxy → Forward Proxy
Reverse proxy sends response back to forward proxy, preserving client anonymity.
Forward proxy may cache or filter response before sending to client.
6
Forward Proxy → Client
Forward proxy sends final response to client, completing the request cycle.
Forward proxy completes the request cycle by delivering the response to the client.

Practice

(1/5)
1. In the trace propagation flow, at step 4 the downstream Service B receives an HTTP request with trace headers. What does Service B's instrumentation do at this step?
easy
A. Starts a new root trace ignoring incoming trace headers
B. Sends trace data directly to the trace storage without processing
C. Drops trace headers to reduce overhead and logs locally only
D. Extracts trace context from headers and starts a child span linked to the parent

Solution

  1. Step 1: Understand instrumentation behavior on incoming requests

    At step 4, Service B's instrumentation extracts the trace context from incoming HTTP headers and starts a new span as a child of the parent span to maintain trace continuity.

  2. Step 2: Eliminate incorrect behaviors

    Starting a new root trace breaks trace linkage. Sending data directly to storage without processing is not the instrumentation's role. Dropping headers loses trace continuity.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Service B extracts context and starts child span [check]
Hint: Extract incoming context, start child span to continue trace [OK]
Common Mistakes:
2. A system requires handling 1 million writes per second with guaranteed durability and ordered processing per user session. Which database technology best fits this requirement?
easy
A. Use a distributed log-based system like Kafka partitioned by user session
B. Use a relational database with row-level locking to ensure order and durability
C. Use an in-memory key-value store like Redis without persistence enabled
D. Use a NoSQL document store with eventual consistency and no ordering guarantees

Solution

  1. Step 1: Identify ordering and durability needs

    Relational DBs with row-level locking can't handle 1M writes/sec efficiently; Redis without persistence loses durability; NoSQL eventual consistency lacks ordering guarantees.

  2. Step 2: Recognize Kafka's partitioning for ordering

    Kafka partitions by user session ensure ordered processing and durability at high throughput.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka partitions -> ordered, durable, high-throughput writes [check]
Hint: Kafka partitions preserve order and durability at scale [check]
Common Mistakes:
3. If Zookeeper's session timeout mechanism fails to detect a crashed leader node promptly, what is the most likely failure observed in the leader election process?
medium
A. Multiple nodes simultaneously assume leadership causing split-brain
B. Leader election proceeds normally due to backup leader election mechanism
C. Followers wait indefinitely for leader node removal, blocking leader election
D. Clients receive stale configuration but leader election continues

Solution

  1. Step 1: Understand session timeout role

    Session timeout detects leader failure by ephemeral node removal.

  2. Step 2: Failure of timeout detection

    If timeout fails, ephemeral node remains, so followers do not start election; no split-brain occurs.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Backup election mechanisms prevent split-brain despite timeout failure [check]
Hint: Session timeout failure -> ephemeral node stays -> no immediate election [check]
Common Mistakes:
4. At 10x scale, which component in a saga-based event-driven system is most likely to fail first due to stateful bottlenecks, and why?
hard
A. The saga coordinator, because it maintains in-memory state per saga and cannot shard easily
B. The message broker, because partition count limits throughput and ordering guarantees
C. The database, because increased writes cause lock contention on outbox tables
D. The event relay service, because network bandwidth saturates before CPU

Solution

  1. Step 1: Identify stateful bottleneck

    The saga coordinator holds per-saga state in memory, limiting horizontal scaling and sharding.

  2. Step 2: Compare other components

    Message brokers scale with partitions; DB scales with sharding; relay is stateless and network-bound.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Saga coordinator's in-memory state limits scaling first [check]
Hint: Stateful saga coordinator limits scaling before stateless components [check]
Common Mistakes:
5. At 10x scale, which component in a gRPC internal service communication system is most likely to fail first and why?
hard
A. gRPC server's streaming connection handler due to stateful HTTP/2 streams per client
B. Protocol Buffers serialization CPU bottleneck due to large message sizes
C. Load balancer because it cannot handle increased TCP connections
D. Service registry because of increased service instance churn

Solution

  1. Step 1: Identify stateful components at scale

    gRPC streaming uses HTTP/2 streams bound to server memory per client, limiting horizontal scaling.

  2. Step 2: Compare bottlenecks

    Protocol Buffers serialization is CPU intensive but parallelizable. Load balancers and service registries scale better with standard techniques. Stateful streaming handlers are the first to hit resource limits.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful HTTP/2 streams -> server connection handler bottleneck [check]
Hint: Stateful streams -> server connection handler bottleneck first [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