Free lesson · System Design Interviews

Networking in Interviews - What to Say and When

Easy11 min readsystem-designinterview-prep

Let me tell you about the networking trap. In my first system design interview at Amazon, I was asked to design a URL shortener. Simple enough. I started drawing boxes - client, server, database. Then the interviewer asked: "Walk me through what happens when the user types the short URL into their browser."

And I panicked. I started at TCP handshakes, went through DNS resolution, talked about TLS certificates, described HTTP headers, explained keep-alive connections. Five minutes later, the interviewer interrupted me. "That's a lot of networking detail. Can we talk about the actual system?"

I'd spent a quarter of my interview time on something the interviewer didn't need. Here's the lesson: networking knowledge in system design interviews is about knowing which layer to discuss at which moment - not about proving you understand the OSI model.

This lesson teaches you the networking concepts that actually come up in interviews, how deep to go on each, and - just as importantly - when to stop.

The Networking Mental Model for Interviews

Think of networking in system design interviews as three zones:

flowchart TD
    subgraph GREEN["Zone 1: Always Mention"]
        DNS["DNS Resolution"]
        LB["Load Balancers"]
        CDN["CDNs"]
        PROTO["HTTP vs WebSocket<br/>vs gRPC"]
    end
    
    subgraph YELLOW["Zone 2: Mention When Relevant"]
        TLS["TLS / HTTPS"]
        PROXY["Reverse Proxies"]
        APIGW["API Gateways"]
        CORS["CORS / Same-origin"]
    end
    
    subgraph RED["Zone 3: Only If Asked"]
        TCP["TCP vs UDP details"]
        OSI["OSI layers"]
        ROUTING["IP routing, BGP"]
        HANDSHAKE["TCP handshake details"]
    end

This diagram organizes networking concepts into three zones for interviews. Zone 1 includes DNS, load balancers, CDNs, and protocol choice - always mention these. Zone 2 includes TLS, reverse proxies, API gateways, and CORS - mention when relevant. Zone 3 includes TCP vs UDP details, OSI layers, IP routing, and TCP handshakes - only discuss if directly asked.

Important: The single biggest networking mistake in interviews: going too deep too early. The interviewer wants to know you can use networking concepts to build systems - not that you can recite RFCs. Stay in Zone 1 unless the problem specifically calls for Zone 2 or 3.

DNS - The First Thing That Happens

Every system design answer that involves a user typing a URL or accessing a service starts with DNS. You don't need to explain DNS in detail - you need to know when to mention it and what it enables.

What to Say

DNS translates human-readable domain names (like api.myapp.com) to IP addresses. In interviews, DNS matters for three reasons:

1. Load distribution: DNS can return different IP addresses for the same domain, distributing traffic across multiple servers or data centers (DNS round-robin).
2. Geographic routing: DNS can return the IP of the nearest data center based on the client's location (GeoDNS).
3. Failover: If a data center goes down, DNS can stop returning its IP address, routing traffic to healthy data centers.

sequenceDiagram
    participant User
    participant DNS as DNS Resolver
    participant CDN as CDN Edge
    participant LB as Load Balancer
    participant Server

    User->>DNS: Resolve api.myapp.com
    DNS-->>User: 52.94.76.100 (nearest DC)
    User->>CDN: GET /static/image.png
    CDN-->>User: Cached response (hit)
    User->>LB: GET /api/feed
    LB->>Server: Forward request
    Server-->>LB: Response
    LB-->>User: Response

This sequence diagram shows a typical request flow. The user first resolves the domain name through DNS, which returns the IP of the nearest data center. Static content like images goes through the CDN and is served from cache. API requests hit the load balancer, which forwards them to a backend server.

How Deep to Go

Tip: Don't say "DNS round-robin" for serious load balancing. DNS doesn't know if a server is healthy or overloaded. Say "DNS for geographic routing to the right data center, then a proper load balancer within the data center for health-aware distribution."

Load Balancers - Every System Has One

If your design has more than one server, you need a load balancer. This comes up in literally every system design interview. You need to know the types, the algorithms, and when each matters.

Layer 4 vs. Layer 7

Load Balancing Algorithms

Interview: What to say: "I'd put an L7 load balancer in front of the API servers - something like an ALB or Nginx. L7 because I need to route different URL paths to different backend services: /api/users goes to the user service, /api/orders goes to the order service. For the algorithm, I'd start with round-robin since our servers are identical, but switch to least-connections if we find that some requests (like report generation) take significantly longer than others."

Follow-up you should expect: "What if the load balancer itself goes down?" Answer: "Run two load balancers in active-passive or active-active configuration. In cloud environments, managed load balancers like ALB are inherently redundant across availability zones."

CDNs - The Fastest Answer to "How Do You Handle Global Scale?"

A Content Delivery Network caches your content at edge servers around the world, so users get responses from a server geographically close to them instead of your origin server that might be on another continent.

What CDNs Cache

Static content (always cache): Images, CSS, JavaScript, fonts, videos. These don't change between users or requests.

Dynamic content (sometimes cache): API responses that are the same for many users (trending posts, product catalog pages). Cache with short TTLs (30-60 seconds).

User-specific content (never cache at CDN): User profiles, shopping carts, authentication tokens. This must come from origin.

Pull vs. Push CDN

Interview: The pattern that earns points: "For static assets - images, CSS, JS - I'd serve them through a CDN like CloudFront with long TTLs (24 hours). For the API responses on the home feed, I'd cache at the CDN layer with a 30-second TTL since the feed doesn't need to be real-time for most users. This offloads the vast majority of traffic from our origin servers."

What often gets missed: CDN invalidation. "When we deploy new frontend code, I'd use versioned filenames (app.v2.3.js) rather than invalidating CDN caches. Versioned names ensure users get the new file immediately without waiting for TTL expiry."

Protocol Choice - HTTP, WebSocket, gRPC, SSE

One of the most common interview questions is "How do your clients communicate with your backend?" The answer is almost always HTTP for most things, but you need to know when to reach for something else.

Decision Framework

flowchart TD
    START["Client needs to<br/>communicate with server"] --> Q1{Direction?}
    Q1 -->|Client → Server<br/>request/response| Q2{Internal or<br/>external?}
    Q1 -->|Server → Client<br/>push updates| Q3{Frequency of<br/>updates?}
    Q1 -->|Bidirectional<br/>real-time| WS["WebSocket"]
    
    Q2 -->|External / public API| REST["REST over HTTP"]
    Q2 -->|Internal service-to-service| Q4{Need streaming?}
    Q4 -->|No| GRPC["gRPC"]
    Q4 -->|Yes| GRPC_STREAM["gRPC streaming"]
    
    Q3 -->|Infrequent<br/>seconds to minutes| POLL["Long polling /<br/>Short polling"]
    Q3 -->|Frequent<br/>continuous stream| SSE["Server-Sent<br/>Events (SSE)"]

This flowchart guides protocol choice. For client-to-server request/response, external APIs use REST over HTTP and internal services use gRPC. For server-to-client push updates, infrequent updates use long polling and frequent continuous streams use Server-Sent Events. For bidirectional real-time communication, use WebSocket.

Protocol Comparison

Warning: Don't say "WebSocket" for everything real-time. If the communication is one-directional (server pushing updates to the client), SSE is simpler and works over regular HTTP. WebSocket is for bidirectional real-time - chat, collaborative editing, multiplayer games. Using WebSocket when you only need server-push is over-engineering.

Reverse Proxies and API Gateways - When to Mention Each

A reverse proxy sits between clients and your servers. All traffic goes through it. It can handle SSL termination, compression, caching, and routing.

An API gateway is a reverse proxy with extra features for API management: authentication, rate limiting, request transformation, API versioning, analytics.

Interview: When to mention a reverse proxy: When you're discussing how traffic enters your system. "Clients hit Nginx, which terminates SSL, compresses responses, and forwards to the appropriate backend service."

When to mention an API gateway: When you have multiple backend services and need centralized auth, rate limiting, or versioning. "The API gateway handles authentication and rate limiting at the edge, so individual services don't need to implement it themselves."

TLS/HTTPS - What to Know

You don't need to explain the TLS handshake in detail. You need to know:

1. Everything should be HTTPS. If asked, just state it as a given: "All communication is over HTTPS."
2. SSL termination at the load balancer means the LB decrypts HTTPS traffic and forwards plain HTTP to backend servers. This offloads CPU-intensive encryption from your app servers.
3. TLS adds latency - the handshake is 1-2 round trips. This is why persistent connections (HTTP/2, gRPC, WebSocket) matter: you pay the TLS cost once, not per request.

Tip: If an interviewer asks about security, don't launch into TLS details. Focus on: "HTTPS for transport, authentication at the API gateway, authorization in the service layer, encryption at rest for sensitive data." That's the security answer they're looking for in a system design interview.

Putting It All Together - A Complete Request Flow

When an interviewer says "Walk me through what happens when a user opens the app," here's the complete pattern at the right level of detail:

sequenceDiagram
    participant Client as Mobile App
    participant DNS
    participant CDN
    participant GW as API Gateway
    participant LB as Load Balancer
    participant SVC as Backend Service
    participant Cache as Redis Cache
    participant DB as Database

    Client->>DNS: Resolve api.myapp.com
    DNS-->>Client: IP of nearest region
    
    Note over Client,CDN: Static assets (images, JS)
    Client->>CDN: GET /static/logo.png
    CDN-->>Client: Cached response
    
    Note over Client,DB: API requests
    Client->>GW: GET /api/feed (with auth token)
    GW->>GW: Validate token, rate limit check
    GW->>LB: Forward to feed service
    LB->>SVC: Route to healthy instance
    SVC->>Cache: Check cache for feed
    Cache-->>SVC: Cache miss
    SVC->>DB: Query feed data
    DB-->>SVC: Feed results
    SVC->>Cache: Store in cache (TTL 30s)
    SVC-->>LB: Feed response
    LB-->>GW: Response
    GW-->>Client: JSON response

This sequence diagram shows a complete request flow. The client resolves the domain through DNS. Static assets are served directly from the CDN. For API requests, the client hits the API gateway, which validates the auth token and checks rate limits. The gateway forwards to a load balancer, which routes to a healthy backend service. The service checks Redis cache first, queries the database on a miss, stores the result in cache, and returns the response back through the chain.

Interview: Use this exact flow when the interviewer asks you to walk through a request. It demonstrates you understand each networking layer without going too deep on any one. Spend about 60-90 seconds on it, then move to the interesting design decisions.

Key Takeaways

1. Stay in Zone 1. DNS, load balancers, CDNs, and protocol choice come up in every interview. OSI layers and TCP handshakes almost never do. Don't volunteer depth you weren't asked for.

2. DNS is one sentence, not five. "DNS resolves the domain to the nearest data center" is enough. Only go deeper if asked about multi-region or failover.

3. Know L4 vs. L7 load balancers. L4 is fast but dumb. L7 is slower but can route by URL, header, or cookie. Most system designs need L7.

4. CDN everything static. Images, CSS, JS, fonts - all through a CDN with long TTLs. API responses can go through CDN with short TTLs.

5. Pick the right protocol. HTTP/REST for public APIs. gRPC for internal services. WebSocket for bidirectional real-time. SSE for server push. Don't use WebSocket when SSE is sufficient.

6. Practice the complete request flow. The "walk me through a request" question comes up in almost every interview. Rehearse the DNS → CDN/LB → Gateway → Service → Cache → DB flow until it's automatic.

Exercise: Exercise 1: You're designing a ride-sharing app. Walk through the networking stack: what protocols do you use between the driver's phone and your servers? Between your servers internally? How do you push real-time location updates?

Exercise 2: Your global e-commerce site serves users in 12 countries. Describe your CDN strategy: what gets cached at the CDN, what TTLs do you use, how do you handle CDN invalidation on product updates?

Exercise 3: An interviewer asks "Should you use REST or gRPC for your microservices?" Give the answer using the four-step tradeoff pattern from Lesson 2.3: name the tradeoff, state your choice, justify with requirements, acknowledge the cost.

Back to System Design Interviews