HTTP and HTTPS in HLD - Scalability & System Analysis

Scalability Analysis - HTTP and HTTPS

Growth Table: HTTP and HTTPS Scaling

Users	Traffic Characteristics	Infrastructure Impact	Security Considerations
100 users	Low requests per second (RPS), mostly HTTP or HTTPS	Single server can handle all traffic	HTTPS overhead negligible, simple SSL cert management
10,000 users	Moderate RPS, mostly HTTPS for security	Need load balancer, multiple servers, SSL termination	SSL handshake CPU cost noticeable, use session resumption
1,000,000 users	High RPS, mostly HTTPS, many concurrent connections	Multiple load balancers, SSL offloading hardware or CDN, caching layers	Use TLS session tickets, OCSP stapling, strong cipher suites
100,000,000 users	Very high RPS, global distribution, HTTPS everywhere	Global CDN with SSL termination, edge caching, distributed load balancers	Automated cert management, strict security policies, DDoS protection

First Bottleneck

The first bottleneck is the SSL/TLS handshake CPU cost on the web servers or load balancers. HTTPS requires encryption and decryption which uses more CPU than HTTP. At moderate to high traffic, this CPU overhead limits how many connections a server can handle.

Scaling Solutions

• SSL Termination at Load Balancer or CDN: Offload encryption work from app servers.
• Use Session Resumption: TLS session tickets or session IDs reduce handshake cost.
• Horizontal Scaling: Add more servers behind load balancers to handle more connections.
• Global CDN: Cache static content and terminate HTTPS close to users to reduce latency and load.
• Hardware Accelerators: Use dedicated SSL/TLS hardware or optimized libraries for encryption.

Back-of-Envelope Cost Analysis

• At 10,000 users, assuming 1 request per second per user -> 10,000 RPS.
• Single server handles ~5,000 concurrent HTTPS connections due to CPU limits.
• Bandwidth: 1 Gbps network supports ~125 MB/s; HTTPS adds ~10-20% overhead.
• Storage for logs and certificates is minimal compared to traffic volume.
• SSL handshake CPU cost can be 10x higher than plain HTTP request processing.

Interview Tip

Start by explaining the difference between HTTP and HTTPS in terms of security and overhead. Then discuss how HTTPS adds CPU and latency costs due to encryption. Identify the SSL handshake as the first bottleneck. Propose offloading SSL to load balancers or CDNs and using session resumption. Finally, mention horizontal scaling and global CDNs for large scale.

Self Check Question

Your web server handles 1000 HTTPS requests per second. Traffic grows 10x to 10,000 RPS. What is your first action and why?

Answer: Offload SSL termination to a load balancer or CDN to reduce CPU load on the web server, because SSL handshakes consume significant CPU and limit concurrency.

Key Result

HTTPS adds CPU overhead due to encryption, making SSL/TLS handshake the first bottleneck as traffic grows. Offloading SSL termination and using CDNs are key to scaling securely.

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