Bird
Raised Fist0

HTTP vs HTTPS - TLS Handshake, Certificate Chain, and the Cost

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
HTTP vs HTTPS - TLS Handshake, Certificate Chain, and the Cost
Design and analyze the TLS handshake process, certificate chain validation, and performance impact of HTTPS over HTTP at scale
mediumNetworking and ProtocolsFreq: common
⚙️
Functional Requirements
  • Support HTTP protocol for unencrypted communication
  • Support HTTPS protocol with TLS 1.3 handshake for encrypted communication
  • Validate server certificate chain during TLS handshake to ensure authenticity
  • Establish secure session keys for encrypted data transfer
  • Allow session resumption to reduce handshake overhead on repeat connections
  • Provide fallback to HTTP if HTTPS handshake fails or is unsupported
📊
Non-Functional Requirements
  • Support 2 billion daily active users (DAU) globally
  • Maintain 99.99% availability for HTTPS connections
  • Achieve TLS handshake latency under 100ms P99 at peak load
  • Handle peak write QPS of 925K TLS handshakes per second
  • Ensure bandwidth overhead due to TLS does not exceed 20% of total outbound traffic
❓
Clarifying Questions to Ask
  • What TLS versions and cipher suites must be supported?
  • Is mutual TLS (client certificate authentication) required or only server-side?
  • What is the expected average and peak connection duration?
  • Are session resumption mechanisms like TLS 1.3 0-RTT or session tickets allowed?
  • What is the expected ratio of new vs resumed TLS sessions?
  • Is hardware acceleration for TLS offloading available in the infrastructure?
Out of Scope
✗ Design of the underlying TCP/IP stack or network routing
✗ Implementation of application-layer protocols beyond HTTP/HTTPS
✗ Certificate Authority (CA) infrastructure and issuance process
✗ Client-side browser or OS TLS implementation details
📌
Assumptions
  • 2 billion DAU globally
  • Average 40 HTTPS connections per user per day
  • Average TLS handshake size (certificate chain + messages) ~5 KB
  • Average message size after handshake ~100 bytes
⚡
QPS Calculation
write qps2B users × 40 connections/day ÷ 86400 sec/day ≈ 925,926 TLS handshakes/sec
peak write qpsAssuming 3× peak factor: 925,926 × 3 ≈ 2.78M TLS handshakes/sec
read qpsAssuming 10× more reads than writes: 925,926 × 10 ≈ 9.26M requests/sec
💾
Storage Estimate
daily storage2B × 40 × 5 KB = 400 TB/day (certificate chain + handshake data)
retention days7
total storage400 TB × 7 = 2.8 PB
with replication2.8 PB × 3 replicas = 8.4 PB total storage
🖥️
Server Estimate
tls termination serversAssuming each server handles 10K TLS handshakes/sec, need 278 servers at peak
certificate validation serversAssuming each server validates 50K cert chains/sec, need 56 servers
🏗️
Architecture Diagram
Architecture Diagram
          +----------------------+
          |   Client (Browser)   |
          +----------+-----------+
                     | HTTP/HTTPS Request
                     v
          +----------+-----------+
          | TLS Termination Load |
          |      Balancer        |
          +----------+-----------+
                     | TLS Handshake + Cert Validation
                     v
          +----------+-----------+
          | TLS Termination Srv |
          | (e.g. Envoy, NGINX) |
          +----------+-----------+
                     | Forward Decrypted HTTP
                     v
          +----------+-----------+
          |   Application Srv   |
          +----------------------+
🧩
Components
Client (Browser/Device)
Initiates HTTP or HTTPS connections, performs TLS handshake
Why thisBrowsers implement TLS 1.3 with optimized handshake and session resumption support
Why notCustom clients lack widespread support and optimizations for TLS 1.3 handshake
TLS Termination Load Balancer
Distributes incoming TLS connections to termination servers, handles initial handshake routing
Why thisEnvoy or AWS ELB supports TLS offloading at scale with health checks and session affinity
Why notDNS-based load balancing lacks fine-grained control and latency optimizations
TLS Termination Server (Envoy/NGINX)
Performs TLS handshake, validates certificate chain, decrypts traffic for backend
Why thisEnvoy supports TLS 1.3, OCSP stapling, session tickets, and hardware acceleration
Why notHAProxy lacks full TLS 1.3 support and hardware offload integration at scale
Certificate Validation Service
Validates certificate chains against trusted CAs, checks revocation status (CRL/OCSP)
Why thisDedicated service offloads expensive cert validation from TLS servers, improves scalability
Why notInline validation on TLS servers causes CPU bottlenecks at 2.78M handshakes/sec
Application Server
Processes decrypted HTTP requests, business logic, and responses
Why thisSeparates concerns, allows scaling app logic independently from TLS termination
Why notCombining TLS and app logic reduces flexibility and increases latency under load
🔄
Data Flow
1
Client → TLS Termination Load Balancer
Client sends HTTPS request initiating TLS handshake
Client hello includes supported cipher suites and session resumption info
2
Load Balancer → TLS Termination Server
Load balancer routes handshake to a TLS termination server
Maintains session affinity for resumed sessions
3
TLS Termination Server → Certificate Validation Service
Server sends server certificate chain for validation
Validation includes chain integrity and revocation status
4
Certificate Validation Service → TLS Termination Server
Returns validation result (valid/invalid)
Invalid cert aborts handshake; valid proceeds to key exchange
5
TLS Termination Server → Client
Completes TLS handshake, establishes session keys
Encrypted channel established for HTTP data
6
TLS Termination Server → Application Server
Forwards decrypted HTTP request
Application server processes request without TLS overhead
7
Application Server → TLS Termination Server
Sends HTTP response
TLS server encrypts response and sends back to client

Practice

(1/5)
1. A web application requires multiplexing multiple requests over a single TCP connection to reduce latency. Which HTTP version feature primarily enables this?
easy
A. HTTP/3 using UDP datagrams without multiplexing
B. HTTP/1.1 pipelining with multiple TCP connections
C. HTTP/2 multiplexing streams over one TCP connection
D. HTTP/1.1 using separate TCP connections per request

Solution

  1. Step 1: Identify multiplexing capability

    HTTP/1.1 uses pipelining but suffers head-of-line blocking; HTTP/2 introduces multiplexing streams over a single TCP connection, allowing concurrent requests without blocking.

  2. Step 2: Eliminate other options

    HTTP/3 uses UDP and multiplexing but is not the primary feature here; HTTP/1.1 with multiple TCP connections increases overhead and latency.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    HTTP/2 multiplexes streams on one TCP connection [check]
Hint: HTTP/2 multiplexes streams on one TCP connection [check]
Common Mistakes:
2. For a mobile app with limited control over HTTP headers and caching proxies, which API versioning strategy is best to ensure backward compatibility and cache friendliness?
medium
A. Embed version in the URL path (e.g., /v1/resource) to leverage caching and simple routing
B. Use query parameters to specify version, allowing flexible client control
C. Use a custom HTTP header like X-API-Version to specify version
D. Use content negotiation with Accept header media types for versioning

Solution

  1. Step 1: Consider mobile client and caching constraints

    Mobile clients and caching proxies often ignore or strip custom headers, making header-based versioning unreliable.

  2. Step 2: Evaluate URL versioning benefits

    Embedding version in URL ensures cache keys differ per version, enabling backward compatibility and cache friendliness.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    URL versioning works best with caching proxies and limited header control [check]
Hint: URL versioning beats headers for caching and mobile clients [check]
Common Mistakes:
3. If Redis becomes unavailable in a centralized rate limiting system, what is the immediate failure mode for incoming requests?
medium
A. API servers allow all requests without rate limiting, risking overload
B. Requests are queued locally until Redis recovers, causing increased latency
C. API servers reject all requests immediately to avoid exceeding limits
D. API servers switch to a backup Redis instance automatically without delay

Solution

  1. Step 1: Understand Redis unavailability impact

    Without Redis, the centralized counter is unreachable, so rate limiting cannot be enforced.

  2. Step 2: Check fallback behavior

    Most implementations allow requests to proceed without rate limiting to avoid blocking, risking overload.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Redis down -> no rate limiting -> requests allowed unchecked [check]
Hint: No Redis means no rate limiting, requests pass unchecked [check]
Common Mistakes:
4. For an API serving millions of users with varying traffic patterns, which rate limiting strategy best balances fairness and system protection?
medium
A. Use a global fixed window counter resetting every minute for all clients
B. Use a simple fixed quota per client without burst allowance
C. Use a token bucket algorithm per client to allow bursty traffic within limits
D. Use a leaky bucket algorithm globally to smooth all incoming requests

Solution

  1. Step 1: Evaluate fixed window and global approaches

    Global fixed window (A) causes unfairness and synchronized spikes; global leaky bucket (D) smooths but penalizes all clients equally.

  2. Step 2: Compare per-client token bucket vs fixed quota

    Fixed quota (C) disallows bursts, hurting user experience; token bucket (B) allows bursts while enforcing long-term limits, balancing fairness and protection.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Token bucket per client allows controlled bursts [check]
Hint: Token bucket per client balances bursts and fairness [check]
Common Mistakes:
5. At 10x traffic scale, which cache invalidation component is most likely to become the bottleneck first and why?
hard
A. Client cache control headers, as client diversity increases cache misses
B. TTL expiration mechanism, because it requires scanning all cached objects frequently
C. Surrogate key mapping store, because maintaining and querying large key-object mappings grows exponentially
D. Purge API service, due to synchronous invalidation requests overwhelming the control plane

Solution

  1. Step 1: Analyze TTL expiration scalability

    TTL expirations are typically handled by distributed timers or lazy expiry, scaling well.

  2. Step 2: Evaluate purge API load

    Purge API handles synchronous invalidation requests; at 10x scale, request volume can overwhelm it causing delays.

  3. Step 3: Consider surrogate key store and client headers

    Surrogate key stores scale with sharding; client headers affect cache hit ratio but not invalidation bottleneck.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Purge API synchronous requests bottleneck at high scale [check]
Hint: Purge API sync invalidations bottleneck 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