HTTP and HTTPS in HLD - System Design Exercise

Design: HTTP and HTTPS Communication System

Design focuses on the communication protocols HTTP and HTTPS between clients and servers, including encryption, authentication, and request handling. It excludes detailed web server internals, application logic, and client UI design.

Functional Requirements

FR1: Allow clients to request web resources from servers using HTTP protocol

FR2: Support secure communication using HTTPS with encryption

FR3: Ensure data integrity and confidentiality during transmission

FR4: Handle multiple concurrent client requests efficiently

FR5: Provide mechanisms for server authentication to clients

FR6: Support redirection from HTTP to HTTPS

FR7: Allow caching of resources to improve performance

Non-Functional Requirements

NFR1: Support at least 10,000 concurrent client connections

NFR2: API response latency p99 under 200ms

NFR3: Availability target of 99.9% uptime

NFR4: Encryption overhead should not degrade performance beyond 10%

NFR5: Support modern web browsers and HTTP/1.1 and HTTP/2 protocols

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Web server supporting HTTP and HTTPS

TLS/SSL certificate management

Load balancer for distributing requests

Cache layer (browser and server-side)

Certificate Authority (CA) for authentication

Redirect service from HTTP to HTTPS

Design Patterns

TLS handshake and encryption pattern

Reverse proxy pattern for SSL termination

Caching pattern for static resources

Load balancing pattern for scalability

Redirection pattern for HTTP to HTTPS

Reference Architecture

Load Balancer

↓

Web Server with TLS Termination

↓

Application Server / Static Content

↓

Certificate Authority

Components

Client Browser

Modern Web Browsers (Chrome, Firefox, Safari, Edge)

Initiates HTTP/HTTPS requests and handles responses, including caching and certificate validation

Load Balancer

Nginx, HAProxy, AWS ELB

Distributes incoming HTTP/HTTPS requests across multiple web servers for scalability and availability

Web Server with TLS Termination

Nginx, Apache, Caddy

Handles HTTP and HTTPS requests, performs TLS handshake and encryption/decryption, serves static content or forwards to application servers

Application Server / Static Content Server

Node.js, Java Spring Boot, Static File Server

Processes dynamic requests or serves static files as requested by the web server

TLS/SSL Certificate Management

Let's Encrypt, Certbot, Commercial CAs

Manages issuance, renewal, and revocation of TLS certificates to enable HTTPS

Certificate Authority (CA)

Public or Private CA infrastructure

Issues trusted certificates to servers for authentication during TLS handshake

Cache Layer

Browser cache, CDN, Reverse Proxy Cache

Stores frequently accessed resources to reduce latency and server load

Request Flow

1. Client browser sends HTTP request to server via load balancer.

2. If request is HTTP and HTTPS is required, load balancer or web server redirects client to HTTPS URL.

3. Client initiates TLS handshake with web server for HTTPS connection.

4. Web server and client exchange certificates and establish encrypted session.

5. Client sends encrypted HTTP request over TLS.

6. Web server decrypts request and forwards to application server or serves static content.

7. Application server processes request and returns response to web server.

8. Web server encrypts response and sends back to client.

9. Client browser decrypts response and renders content.

10. Caching mechanisms store resources to optimize future requests.

Database Schema

Not applicable as this design focuses on communication protocols and encryption rather than data storage.

Scaling Discussion

Bottlenecks

Load balancer can become a single point of failure under high traffic.

TLS handshake is CPU intensive and can limit concurrent connections.

Web server may become overwhelmed serving static and dynamic content.

Certificate management complexity increases with many domains.

Cache invalidation and consistency challenges at scale.

Solutions

Use multiple load balancers with health checks and failover.

Offload TLS termination to dedicated hardware or reverse proxies.

Separate static content serving to CDN or dedicated servers.

Automate certificate issuance and renewal with ACME protocol.

Implement cache invalidation strategies and use CDN for global caching.

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain difference between HTTP and HTTPS and why encryption matters.

Describe TLS handshake and certificate role in authentication.

Discuss how load balancers and reverse proxies help scalability and security.

Highlight caching benefits and challenges in web communication.

Address how to handle certificate lifecycle and redirection.

Mention performance impact of encryption and mitigation strategies.

Practice

1. What is the main difference between HTTP and HTTPS?

easy

A. HTTPS encrypts data while HTTP does not

B. HTTP encrypts data while HTTPS does not

C. HTTP is faster because it uses encryption

D. HTTPS does not use any encryption

Solution

1. Step 1: Understand HTTP basics

   HTTP transfers data without encryption, so data can be seen by others.

2. Step 2: Understand HTTPS encryption

   HTTPS adds encryption to protect data from being read by others during transfer.

3. Final Answer:

   HTTPS encrypts data while HTTP does not -> Option A

4. Quick Check:

   Encryption = HTTPS [OK]

Hint: HTTPS always means encrypted data transfer [OK]

Common Mistakes:

• Thinking HTTP encrypts data
• Believing HTTPS is slower because of encryption
• Confusing HTTP and HTTPS roles

2. Which URL prefix indicates a secure connection using HTTPS?

easy

A. http://

B. https://

C. ftp://

D. file://

Solution

1. Step 1: Identify URL prefixes

   URLs starting with http:// use HTTP, which is not secure.

2. Step 2: Recognize HTTPS prefix

   URLs starting with https:// use HTTPS, which is secure and encrypted.

3. Final Answer:

   https:// -> Option B

4. Quick Check:

   Secure URL prefix = https:// [OK]

Hint: Secure URLs start with https:// [OK]

Common Mistakes:

• Choosing http:// as secure
• Confusing ftp:// with HTTPS
• Not recognizing URL prefixes

3. Consider this simplified request flow for a website:

1. Client sends HTTP request
2. Server responds with redirect to HTTPS URL
3. Client sends HTTPS request
4. Server sends secure response

What is the main purpose of step 2 in this flow?

medium

A. To encrypt data before sending it

B. To send the website content unencrypted

C. To close the connection immediately

D. To tell the client to use a secure connection

Solution

1. Step 1: Analyze step 2 action

   Server sends a redirect response telling client to change URL to HTTPS.

2. Step 2: Understand redirect purpose

   This redirect forces client to use a secure encrypted connection for next request.

3. Final Answer:

   To tell the client to use a secure connection -> Option D

4. Quick Check:

   Redirect to HTTPS = secure connection [OK]

Hint: Redirects to HTTPS enforce secure connections [OK]

Common Mistakes:

• Thinking redirect encrypts data itself
• Believing redirect closes connection
• Confusing redirect with content delivery

4. A developer wrote this code snippet to check if a URL uses HTTPS:

if url.startswith('http://'):
    print('Secure connection')
else:
    print('Not secure')

What is the error in this code?

medium

A. It should check for 'https://' to confirm security

B. The print statements are reversed

C. The method 'startswith' does not exist

D. It should use 'http://' to confirm security

Solution

1. Step 1: Understand the check logic

   The code checks if URL starts with 'http://', then says 'Secure connection'.

2. Step 2: Identify correct prefix for security

   Only URLs starting with 'https://' are secure, so the check is wrong.

3. Final Answer:

   It should check for 'https://' to confirm security -> Option A

4. Quick Check:

   Check 'https://' for security [OK]

Hint: Check for 'https://' prefix to confirm security [OK]

Common Mistakes:

• Confusing 'http://' as secure
• Reversing print messages
• Using non-existent string methods

5. You are designing a web service that must protect user data and build trust. Which approach best ensures secure communication and user confidence?

hard

A. Use HTTP and encrypt data manually in the application layer

B. Use HTTP for faster data transfer and add a login page

C. Use HTTPS with a valid SSL certificate and redirect all HTTP requests to HTTPS

D. Use HTTPS only on the login page and HTTP elsewhere

Solution

1. Step 1: Identify security needs

   Protecting user data requires encryption for all communication, not just parts.

2. Step 2: Evaluate options for secure design

   Using HTTPS with a valid SSL certificate and redirecting HTTP to HTTPS ensures all data is encrypted and users see trust indicators.

3. Final Answer:

   Use HTTPS with a valid SSL certificate and redirect all HTTP requests to HTTPS -> Option C

4. Quick Check:

   Full HTTPS with redirect = best security [OK]

Hint: Always redirect HTTP to HTTPS with valid SSL for trust [OK]

Common Mistakes:

• Using HTTP for speed over security
• Encrypting only parts of communication
• Mixing HTTP and HTTPS causing confusion