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
45 min · senior
senior

You are designing the network layer for a 50 million daily active user (DAU) startup that requires secure communication between clients and servers. The system must support encrypted traffic (HTTPS) to protect user data and comply with privacy regulations. However, the TLS handshake and certificate validation introduce latency and CPU overhead, impacting user experience. The system must maintain a P99 latency under 200ms for page loads and API calls. Offline delivery of cached content is also required for intermittent connectivity scenarios.

Constraints
  • Encryption (HTTPS) is mandatory for all user traffic due to compliance and privacy.
  • TLS handshake latency must not cause P99 request latency to exceed 200ms.
  • Certificate chain validation must be efficient and secure, supporting revocation checks.
  • Offline content delivery must work without active TLS handshake.
  • System must handle peak load of 50M DAU with average 5 requests per user per day.
📋
Guided Steps
1/5
Step 1
TLS Handshake Flow and Optimization
Describe the TLS handshake process between client and server and how to optimize it for low latency at 50M DAU scale.
💡 Hint
Consider session resumption techniques and TLS 1.3 improvements to reduce round trips.
Key Decision
Use TLS 1.3 with 0-RTT session resumption to minimize handshake latency and CPU overhead on servers.
Interviewer Expectation
Mid-level: Names TLS 1.3 and session resumption. Senior: Explains 0-RTT benefits, replay attack risks, and fallback to full handshake.
⚠️Common Wrong Answer
Using TLS 1.2 without session resumption, causing multiple round trips and high CPU load at scale.
Step 2
Certificate Chain Validation and Revocation
Explain how the server and client validate the certificate chain efficiently and securely, including revocation checks.
💡 Hint
Think about OCSP stapling and CRL distribution points to reduce latency and improve security.
Key Decision
Implement OCSP stapling on the server side to provide timely revocation status without client-side network calls.
Interviewer Expectation
Mid-level: Mentions certificate chain validation and revocation. Senior: Details OCSP stapling benefits, fallback mechanisms, and impact on handshake latency.
⚠️Common Wrong Answer
Clients performing direct OCSP queries causing additional latency and privacy leaks.
Step 3
Handling Offline Content Delivery
Design how the system supports offline content delivery without requiring a TLS handshake on every request.
💡 Hint
Consider caching strategies and how to securely serve cached content when offline.
Key Decision
Use Service Workers with HTTPS caching and signed content bundles to allow offline access without repeated TLS handshakes.
Interviewer Expectation
Mid-level: Describes caching offline content. Senior: Explains signed bundles, cache integrity, and security implications of offline HTTPS content.
⚠️Common Wrong Answer
Serving cached content over HTTP or without signature verification, risking content tampering.
Step 4
Scaling TLS Handshake and Certificate Management
How would you architect the system to handle TLS handshake and certificate management at 50M DAU with minimal latency and CPU overhead?
💡 Hint
Think about load balancers, TLS termination proxies, and certificate caching layers.
Key Decision
Deploy dedicated TLS termination proxies (e.g., Envoy or NGINX) with hardware TLS acceleration and centralized certificate management.
Interviewer Expectation
Mid-level: Names TLS termination proxies. Senior: Explains hardware acceleration benefits, certificate caching, and offloading handshake CPU from app servers.
⚠️Common Wrong Answer
Terminating TLS directly on app servers causing CPU bottlenecks and increased latency.
Step 5
Trade-offs Between HTTP and HTTPS
Discuss the trade-offs between using HTTP and HTTPS in terms of security, performance, and user experience at this scale.
💡 Hint
Consider encryption overhead, user trust, SEO, and compliance requirements.
Key Decision
Choose HTTPS exclusively despite overhead because encryption protects user data, improves SEO, and meets compliance; mitigate overhead with TLS 1.3 and caching.
Interviewer Expectation
Mid-level: Lists pros and cons of HTTP vs HTTPS. Senior: Quantifies latency overhead, explains mitigation strategies, and compliance impact.
⚠️Common Wrong Answer
Using HTTP to reduce latency ignoring security and compliance consequences.
🔌
API Design Challenge
Sketch 3 core API endpoints that illustrate how clients establish secure connections, fetch content, and handle offline scenarios.
Hints
  • How does the client initiate and complete the TLS handshake with the server?
  • How does the client request content securely after handshake completion?
  • How does the client sync or refresh cached content when offline and reconnecting?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Explain TLS 1.3 handshake optimizations and session resumption impact on latency.
  • Describe OCSP stapling and its role in certificate revocation checks.
  • Design offline content delivery with secure caching under HTTPS.
  • Architect TLS termination with hardware acceleration to scale CPU usage.
Good to Have - 30%
  • Discuss trade-offs between HTTP and HTTPS including compliance and SEO.
  • Mention automated certificate management and renewal processes.
  • Explain risks and mitigations of TLS 0-RTT early data.
Bonus - 10%
  • Quantify latency improvements with TLS 1.3 vs TLS 1.2 at 50M DAU scale.
  • Propose metrics to monitor TLS handshake failures and certificate expiry.
Anti-patterns to Avoid
Terminating TLS on app servers causes CPU bottlenecks and increased latency, reducing system scalability and user experience.
Clients performing direct OCSP queries increase latency and leak user browsing patterns, compromising privacy and performance.
Serving offline cached content over HTTP or unsigned bundles risks content tampering and security breaches.
Using HTTP to avoid TLS overhead ignores security and compliance requirements, exposing user data to interception.
Ignoring replay attack risks when using TLS 0-RTT early data can lead to unauthorized request replays and data breaches.
Not automating certificate renewal leads to expired certificates causing service downtime and loss of user trust.
✅
Model Answer
▼ Reveal

The system uses TLS 1.3 with 0-RTT session resumption and OCSP stapling to minimize handshake latency and secure certificate validation. Offline content is served via signed bundles cached by Service Workers under HTTPS. TLS termination is offloaded to hardware-accelerated proxies to scale CPU usage efficiently.

Key Decisions
  • Adopt TLS 1.3 with 0-RTT to reduce handshake latency and CPU load, while implementing replay attack mitigations.
  • Enable OCSP stapling on TLS termination proxies to eliminate client-side revocation queries and reduce latency.
  • Use Service Workers with signed content bundles to securely serve offline content without repeated TLS handshakes.
  • Offload TLS handshake processing to dedicated proxies with hardware acceleration to handle 50M DAU scale efficiently.
  • Implement automated certificate renewal pipelines to prevent downtime due to expired certificates.
  • Enforce strict HTTPS-only policy to comply with privacy regulations and improve user trust and SEO.
  • TLS 1.3 with 0-RTT session resumption reduces handshake latency to near zero on resumed sessions.
  • OCSP stapling eliminates client-side revocation queries, reducing handshake latency and privacy leaks.
  • Service Workers enable offline HTTPS content delivery with signed bundles ensuring integrity and security.
  • Dedicated TLS termination proxies (Envoy/NGINX) with hardware acceleration offload CPU-intensive handshake tasks from app servers.
  • Centralized certificate management with automated renewal (e.g., Let's Encrypt + Certbot) ensures valid certificates at scale.
  • Strict HTTPS-only policy improves user trust, SEO ranking, and meets GDPR/CCPA compliance despite added handshake cost.
  • Caching TLS session tickets and certificate chains on proxies reduces redundant cryptographic operations.
  • TLS False Start and Early Data (0-RTT) trade-offs must be carefully managed to avoid replay attacks.

Practice

(1/5)
1. In the message delivery trace, at step 4 the Delivery Worker checks the subscriber's presence TTL in Redis. What happens if the TTL has expired at this step?
easy
A. The Delivery Worker forwards the message to a backup subscriber
B. The Delivery Worker marks the message as undeliverable and stops retries
C. The Delivery Worker queues the message for later retry after refreshing TTL
D. The Delivery Worker immediately retries delivery without delay

Solution

  1. Step 1: Understand Delivery Worker behavior on subscriber presence TTL expiry

    If TTL expired, subscriber is considered offline. Delivery Worker does not retry immediately (The Delivery Worker immediately retries delivery without delay) or mark undeliverable (The Delivery Worker marks the message as undeliverable and stops retries) because retries are needed. It does not refresh TTL (The Delivery Worker queues the message for later retry after refreshing TTL) as TTL is subscriber-driven.

  2. Step 2: Recognize fallback to backup subscriber for high availability

    Delivery Worker forwards message to backup subscriber or alternative delivery path to ensure eventual delivery.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired TTL -> fallback delivery to backup subscriber [check]
Hint: Expired TTL triggers fallback delivery, not immediate retry [check]
Common Mistakes:
2. For a system supporting multiple client types (web, mobile, IoT), which architecture best balances maintainability and client-specific optimization?
medium
A. Single API Gateway forwarding requests directly to microservices with client logic inside services
B. Separate BFF layers per client type behind a common API Gateway
C. One monolithic backend serving all clients with feature flags for client differences
D. Client apps call microservices directly, bypassing API Gateway and BFF

Solution

  1. Step 1: Evaluate client-specific optimization needs

    Separate BFF layers per client type allow tailored APIs, improving UX and reducing client complexity.

  2. Step 2: Assess maintainability

    Separate BFF layers per client type behind a common API Gateway isolates client-specific logic in BFFs, keeping microservices generic and maintainable. Single API Gateway forwarding requests directly to microservices with client logic inside services mixes client logic into services, increasing coupling. One monolithic backend serving all clients with feature flags for client differences's monolith reduces flexibility and scalability. Client apps call microservices directly, bypassing API Gateway and BFF breaks encapsulation and complicates security.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Separate BFFs isolate client logic, improving maintainability and optimization [check]
Hint: Separate BFFs isolate client logic, improving maintainability [check]
Common Mistakes:
3. If the Kafka broker cluster goes down unexpectedly, what exactly breaks in the message delivery pipeline?
medium
A. Producers receive errors and messages are lost if not retried; consumers stop receiving new messages causing delivery stalls
B. Consumers continue reading cached messages but new messages from producers are lost until broker recovers
C. Producers block indefinitely waiting to write messages, causing backpressure
D. Messages are duplicated because brokers resend uncommitted messages after restart

Solution

  1. Step 1: Trace producer behavior on broker failure

    Producers get errors on send; without retries, messages are lost. They do not block indefinitely (A).

  2. Step 2: Trace consumer behavior

    Consumers cannot fetch new messages; cached messages may be consumed but no new delivery occurs, causing stalls. Duplication (D) is prevented by offset commits.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Broker failure causes producer errors and consumer stalls, risking message loss [check]
Hint: Broker down -> producer errors, consumer stalls, possible message loss [check]
Common Mistakes:
4. If the machine ID component is misconfigured and two machines generate Snowflake IDs with the same machine ID simultaneously, what is the most likely failure mode?
medium
A. The sequence number will automatically adjust to prevent collisions across machines.
B. Duplicate IDs will be generated within the same millisecond causing data corruption or overwrite.
C. IDs generated on both machines will be unique due to different timestamps, no collision occurs.
D. The system will detect the conflict and block one machine from generating IDs.

Solution

  1. Step 1: Understand machine ID role in uniqueness

    Machine ID differentiates ID generators on different machines; same machine ID risks collisions.

  2. Step 2: Analyze collision handling

    Different timestamps alone (A) do not guarantee uniqueness if clocks are synchronized; sequence number does not auto-adjust across machines (C is incorrect). System does not detect conflicts automatically (D).

  3. Step 3: Correct failure mode

    Duplicate IDs are generated if machine IDs collide, causing data corruption or overwrite.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Same machine ID + same timestamp -> duplicate IDs and data corruption [check]
Hint: Same machine ID causes duplicate IDs, no auto correction [OK]
Common Mistakes:
5. At 10x scale, which component in an HTTP/3 deployment is most likely to become the bottleneck first and why?
hard
A. WebSocket servers because HTTP/3 does not support WebSockets natively
B. TLS handshake CPU load on servers due to QUIC's per-connection encryption overhead
C. UDP packet loss rate increases causing retransmissions and latency spikes
D. TCP connection limits because HTTP/3 uses TCP under the hood

Solution

  1. Step 1: Identify HTTP/3 transport and encryption

    HTTP/3 uses QUIC over UDP with built-in TLS encryption per connection, increasing CPU load for handshake and encryption at scale.

  2. Step 2: Eliminate other bottlenecks

    UDP packet loss is network-level, not server bottleneck; WebSockets are not natively supported by HTTP/3 but unrelated to scaling HTTP/3 itself; HTTP/3 does not use TCP.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    QUIC's per-connection TLS handshake CPU load limits HTTP/3 scale [check]
Hint: QUIC TLS handshake CPU load limits HTTP/3 scale 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