What Happens Between a Click and an Answer?

Guide 2 of 5 · Networking and APIs

Series overview · Previous: Foundations and data · Next: Architecture, messaging, and patterns

1. Follow one request

A student opens the library website. The browser needs to find the service, connect to it, ask for data, and understand the reply.

Think of sending a parcel. The address helps it reach the building. The room number helps it reach the right desk. The form inside says what you want done.

In a network, an IP address helps route traffic to a network interface. A port identifies a service endpoint. An application protocol describes the conversation.

The analogy has limits: an IP address can change, several devices can share a public address through address translation, and one service can run at many addresses.

2. IP addresses and network layers

IPv4 addresses use 32 bits. IPv6 uses 128 bits. Documentation examples include 192.0.2.10 and 2001:db8::10; these examples are reserved for documentation.

Public addresses are routable on the public internet when network policy permits. Private IPv4 addresses are used within private networks. A home router often uses NAT, or Network Address Translation, so several devices share one public IPv4 address. That arrangement does not define all public addressing.

Static and dynamic describe how stable an assignment is. A stable address need not be typed manually; an administrator can reserve it through address management.

The OSI model is a learning model that separates networking responsibilities into seven layers. Internet protocols do not map perfectly to every box.

Layer	What to remember	Example or mental picture
7: Application	Meaning of requests and replies	HTTP asks for a resource
6: Presentation	Data representation	Encoding, compression, encryption as conceptual functions
5: Session	Conversation management	Keeping track of an exchange
4: Transport	Communication between endpoints	TCP, UDP, ports
3: Network	Routing packets	IP addresses and routers
2: Data link	Delivery across a local link	Ethernet or Wi-Fi frames
1: Physical	Signals	Radio, copper, light

Use the layers to troubleshoot. A DNS error is different from a connection timeout. A successful connection followed by an HTTP 500 points further up the stack.

3. DNS: the address book

DNS, the Domain Name System, maps names to records. It often helps a browser find an IP address for a hostname.

A recursive resolver finds the answer for a client. On a cache miss, it can ask root, top-level domain, and authoritative servers. The root and TLD servers usually provide referrals. The authoritative server provides records for its zone.

sequenceDiagram
    participant B as Browser
    participant R as Resolver
    participant T as Root and TLD
    participant A as Authoritative DNS
    B->>R: Find library.example address
    alt Cached answer is usable
        R-->>B: Return cached address
    else Lookup required
        R->>T: Find responsible nameservers
        T-->>R: Referrals
        R->>A: Ask for address record
        A-->>R: Address and TTL
        R-->>B: Return address
    end

Root and TLD are grouped to keep this diagram small; they are separate stages in an uncached lookup. Cached referrals, aliases, and other records can change the exact sequence.

Record	Purpose
A	IPv4 address
AAAA	IPv6 address
CNAME	Alias to another name
MX	Mail server destination
TXT	Text data used by several validation mechanisms
NS	Nameservers for a zone
SOA	Zone administration and timing information
SRV	Service target and port
PTR	Reverse lookup from address to name

A zone is an administrative part of DNS. A subdomain is a name below another name; it does not always have its own delegated zone.

TTL, or time to live, controls how long a cached record can normally be reused. DNS changes do not instantly replace every cached answer. DNS-based traffic routing must account for that delay. Health-aware DNS services can avoid unhealthy destinations, but cached answers can still point to them.

4. TCP, UDP, and HTTP are different layers

TCP provides a reliable, ordered byte stream. It detects loss and retransmits data, but a connection can fail. TCP acknowledgment does not mean a reservation was committed to the database. Application success requires an application-level result. TCP specification

UDP sends datagrams without TCP's built-in retransmission or ordering. Applications or protocols built on UDP can add these features. "UDP is always faster" is too broad: actual performance depends on the workload and protocol design.

Need	What to discuss
Transfer all bytes in order	TCP's stream behavior may fit
Interactive audio with late packets	A suitable real-time protocol may discard late data
Reliable communication over UDP	A higher-level protocol must provide the required mechanisms
Web requests	HTTP defines request semantics above transport

HTTP/1.1 and HTTP/2 commonly use TCP. HTTP/3 uses QUIC, a transport built on UDP that includes reliable streams. Using UDP underneath does not make HTTP/3 an unreliable application protocol. HTTP/3 specification

HTTPS means HTTP protected with TLS. Security is covered in guide 4.

5. HTTP: use clear requests and results

An API is a contract between programs. For the library, a request might mean "show this book" or "create my reservation."

Method	Example	Intended meaning
GET	`/books/42`	Read a book representation
POST	`/reservations`	Request creation of a reservation
PUT	`/reading-lists/7`	Replace the target representation
PATCH	`/reading-lists/7`	Apply a partial change
DELETE	`/reservations/81`	Remove or cancel according to the API contract
HEAD	`/books/42`	Read response metadata without the response body

Safe means the method does not request a state change. Logging can still occur. Idempotent means repeating the same request has the same intended effect as making it once. GET, PUT, and DELETE have idempotent semantics. The response code need not be identical each time. POST is not automatically idempotent. HTTP semantics

PATCH behavior depends on the operation: "set title to X" can be idempotent; "add one to counter" is not. An idempotency key can protect a custom POST operation from duplicate effects, as shown in guide 5.

Useful response codes include 200 for success, 201 for creation, 202 for accepted work not yet complete, 400 for an invalid request, 401 for missing or invalid authentication, 403 for denied access, 404 for not found, 409 for a conflict, 429 for too many requests, and 503 for temporary unavailability.

A 202 response must not pretend that background work has finished. Return a job identifier and a way to check its status.

6. REST, GraphQL, and gRPC

REST is an architectural style. Resource-oriented HTTP APIs commonly use parts of it. Strict REST also includes a uniform interface and hypermedia links that guide interactions. REST does not mean that every response must be cached; responses indicate whether caching is allowed.

GraphQL lets clients select fields from a typed schema. A student app could ask for just a book's title and cover. The server still controls authorization and the cost of resolving the request. Nested requests can create many database calls, called the N+1 problem; batching and limits help. GraphQL learning guide

gRPC defines remote operations using service contracts and generated client/server code. It commonly uses Protocol Buffers and supports unary calls and several streaming styles. Give calls deadlines and handle errors; generated code does not make a network call as dependable as a local function. gRPC core concepts

Choice	Good reason to consider it	Trade-off
Resource-oriented HTTP API	Broad client compatibility and familiar tooling	Some screens need multiple requests
GraphQL	Several clients need different combinations of fields	Query cost, authorization, and caching need careful design
gRPC	Typed internal contracts and streaming	Browser integration and debugging need suitable tooling

None is always fastest. Data size, database work, network delay, caching, and implementation often matter more than the API label. OpenAPI can support code generation for HTTP APIs too.

7. Who handles the incoming traffic?

These roles overlap, but they answer different questions.

Component	Everyday picture	Main job
Forward proxy	An organization's outgoing mail desk	Acts on behalf of clients
Reverse proxy	A building reception desk	Receives requests on behalf of servers
Load balancer	A queue manager	Distributes work across instances
API gateway	An API entrance desk	Routing and shared API policies
Backend for Frontend, or BFF	A desk designed for one user group	Shapes responses for a particular client experience

A layer 7 load balancer can also be a reverse proxy. A layer 4 balancer routes using transport information such as addresses and ports. A layer 7 balancer can route using application information such as hostname and path, if it can inspect the traffic.

Round-robin rotates among targets. Weighted routing accounts for different capacities. Least-connections can help with unequal connection durations, but a connection count is not the same as actual work. Hash-based routing can keep related requests together, at the risk of uneven distribution.

Health checks should reflect whether a target can serve useful traffic. Avoid checks so expensive that they overload the service, or so broad that one optional dependency removes all healthy app instances.

A gateway can centralize token validation and rate limits. Each service still needs appropriate business authorization. A mobile BFF may combine several backend reads into one small response; avoid duplicating the same reservation rules across BFFs.

8. CDN: move reusable content closer

A CDN, or Content Delivery Network, stores eligible content at distributed edge locations. It is like keeping popular reference sheets in each classroom instead of sending every student to the main office.

flowchart TD
    U[Student requests cover image] --> E{Edge cache has valid copy?}
    E -->|Yes| S[Serve image]
    E -->|No| O[Fetch from object storage origin]
    O --> C[Cache if policy allows]
    C --> S

With pull caching, an edge fetches missing content when needed. With push or prepositioning, content is placed before demand. Many delivery systems offer a mix of controls.

Versioned file names such as cover-42-v3.jpg make immutable assets easier to cache. Mutable content needs expiry, validation, or invalidation. Do not cache a private student response under a shared key that another student can request.

A CDN miss still costs an origin fetch. The origin must handle cold-cache traffic. A CDN can improve delivery and reduce origin load, but it adds policy, invalidation, and traffic-cost decisions.

9. Live updates without repeatedly refreshing

The student wants to know when a reservation is ready.

Technique	How it works	Fits when	Design concern
Short polling	Client asks at intervals	Updates are infrequent	Empty requests and delayed updates
Long polling	Server holds a request until an update or timeout	Broad HTTP compatibility is helpful	Outstanding requests and reconnect churn
Server-Sent Events, or SSE	Server streams text events in an HTTP response	Updates mainly flow to the browser	Resume position, buffering, idle timeouts
WebSocket	Both sides exchange messages over a persistent channel	Frequent two-way interaction matters	Reconnects, authorization, connection capacity

Long polling creates a new request after a response; it does not necessarily create a new TCP connection each time. SSE does not stop the browser from making separate POST requests. A WebSocket is a channel, not a durable message store.

sequenceDiagram
    participant C as Student app
    participant S as Update service
    participant D as Event history
    C->>S: Connect with last seen event ID
    S->>D: Read allowed events after ID
    D-->>S: Missed updates
    S-->>C: Replay and continue live events
    Note over C,S: Connection breaks
    C->>S: Reconnect with latest processed ID
    S->>D: Resume after that ID

The application needs a retention policy, access checks, and duplicate handling. If the requested history has expired, return a full current-state refresh rather than pretending nothing was missed.

10. Interview practice: questions 11–20

Q11. What happens when I open a website?

The browser resolves the hostname if needed, establishes a protected connection, sends an HTTP request, and processes the response. Caches, proxies, and load balancers can participate. Existing connections and caches may skip some work.

Q12. Is a TCP acknowledgment enough to confirm a reservation?

No. It confirms transport progress, not a business transaction. The application must confirm durable success or expose a way to resolve an uncertain result.

Q13. What makes an HTTP operation idempotent?

Repeating it has the same intended effect as doing it once. Repeated deletion can be idempotent even if the first response is 204 and a later one is 404.

Q14. When would you choose GraphQL?

When clients need different combinations of related fields and the benefit justifies server-side query management. I would budget query cost, batch data access, and authorize the requested data.

Q15. Why use gRPC internally?

Typed contracts, generated code, and streaming can help service communication. I would also account for deadlines, compatibility, observability, and clients that cannot use native gRPC directly.

Q16. Is an API gateway the same as a load balancer?

No. Load balancing distributes work. A gateway manages API-facing concerns. One product can perform both roles, so I explain the responsibilities rather than count boxes.

Q17. How can DNS slow failover?

Clients and resolvers may keep cached addresses. Health-aware routing helps new answers, but cannot instantly replace every existing cached answer or connection.

Q18. What belongs in a CDN?

Content that is safe and useful to reuse under a defined cache policy. Book covers fit well. Private reservation data needs protection against shared-cache leakage.

Q19. SSE or WebSocket for reservation status?

SSE is a reasonable option for mostly server-to-browser status updates. I would choose WebSocket when frequent two-way messaging warrants its extra connection-management work.

Q20. How do live updates survive reconnection?

Store a resumable event history or provide state reconciliation. Clients reconnect with their last processed position and handle duplicates. The transport alone does not supply this business behavior.

Quick revision

Addresses locate endpoints. DNS resolves names. Transports carry data. HTTP defines requests. Gateways enforce shared API policies. CDNs cache eligible content. Every network call can have an uncertain outcome, so design for timeouts and recovery.