Question 1

Explain the TCP 3-way handshake.

Accepted Answer

The TCP three-way handshake establishes a reliable, ordered connection between a client and server before any application data is exchanged. It serves two purposes: confirming bidirectional connectivity and synchronizing the initial sequence numbers (ISNs) that TCP uses to order and acknowledge segments.

The three steps are: First, the client sends a SYN (synchronize) segment to the server with a randomly chosen initial sequence number — call it x. This signals the client's intent to open a connection and establishes the client's starting sequence number. Second, the server responds with a SYN-ACK segment: it acknowledges the client's SYN by sending ACK number x+1 (confirming it received x and expects x+1 next), and simultaneously sends its own SYN with its own randomly chosen sequence number y. Third, the client sends an ACK to the server with acknowledgment number y+1, confirming receipt of the server's SYN. After this, both sides have agreed on sequence numbers and the connection is established.

Why random initial sequence numbers? If ISNs were predictable or always started at 0, an attacker could forge packets in an existing connection by guessing the sequence number — a TCP sequence prediction attack. Randomization prevents this.

After the handshake, both sides maintain state: the client moves from SYN_SENT to ESTABLISHED, the server moves from SYN_RECEIVED to ESTABLISHED. Connection teardown is a separate four-way process using FIN and ACK segments, because each direction of the connection closes independently.

Performance implications: the handshake requires 1.5 round trips before any application data can be sent, adding latency. This is why HTTP/2 multiplexes streams over one TCP connection (avoiding repeated handshakes), and QUIC (used by HTTP/3) integrates the transport and cryptographic handshakes to achieve 0-RTT connection resumption for known servers.

SYN flood attacks exploit the handshake: an attacker sends many SYN segments without completing the handshake, exhausting the server's half-open connection table. SYN cookies are the primary mitigation — the server encodes connection state into the ISN rather than storing it, deferring allocation until the ACK arrives.

Question 2

How does TLS work? Explain certificates, Diffie-Hellman, and AES.

Accepted Answer

TLS (Transport Layer Security) provides authentication, confidentiality, and integrity for network connections. It layers three distinct mechanisms to solve three distinct problems: certificates for authentication, Diffie-Hellman for key exchange, and AES for bulk encryption.

Certificates solve the authentication problem: how do you know you're talking to the real server and not an impersonator? A certificate is a digital document issued by a Certificate Authority (CA) that binds a public key to a domain name. The CA signs the certificate with its own private key. Your browser ships with a trust store of root CA public keys. When the server presents its certificate, the browser verifies the CA's signature, confirms the domain matches, and checks the certificate hasn't expired or been revoked. This chain of trust means you only need to trust a small set of CAs — not every server individually. Certificate transparency logs (CT logs) provide public auditability of all issued certificates, making misissuance detectable.

Diffie-Hellman key exchange solves the key distribution problem: how do two parties establish a shared secret over a channel that attackers can observe? In DH, each side generates an ephemeral key pair. They exchange public keys in plaintext. Through the mathematical structure of DH (or its elliptic curve variant, ECDH), each side can compute the same shared secret — but an eavesdropper who sees only the public values cannot compute it without solving the discrete logarithm problem. Modern TLS uses ephemeral ECDH (ECDHE) so each session uses fresh keys — providing forward secrecy: compromise of the server's long-term private key doesn't decrypt past sessions.

AES solves the bulk encryption problem efficiently. Once the shared secret is established, TLS derives symmetric session keys. AES-GCM (Galois/Counter Mode) is standard in TLS 1.3 — it provides both encryption (confidentiality) and authentication (integrity via a message authentication code) in one pass. AES is used rather than asymmetric cryptography for data because symmetric encryption is orders of magnitude faster.

TLS 1.3 (current standard) streamlines this: 1-RTT handshakes with mandatory ECDHE and AEAD ciphers, removal of weaker options like RSA key exchange (which lacks forward secrecy) and CBC mode ciphers. The full handshake: ClientHello (supported ciphers, DH key share) → ServerHello (chosen cipher, DH key share, certificate) → client verifies certificate, both derive session keys, application data flows.

Question 3

What is the difference between TCP and UDP?

Accepted Answer

TCP and UDP are both transport layer protocols that sit on top of IP, but they make fundamentally different trade-offs between reliability and performance.

TCP is a connection-oriented protocol. Before any data is sent, the client and server perform a three-way handshake (SYN, SYN-ACK, ACK) to establish a connection. TCP guarantees reliable, ordered delivery of data through sequence numbers on every segment, acknowledgments from the receiver, and automatic retransmission of lost packets. TCP also provides flow control via a sliding window mechanism and implements congestion control algorithms that adapt the sending rate to network conditions.

The cost of these guarantees is overhead and latency. The three-way handshake adds a round trip before data transfer begins. Every segment must be acknowledged, and if a packet is lost, subsequent data is held until the missing segment is retransmitted (head-of-line blocking). TCP headers are 20-60 bytes.

UDP is a connectionless protocol. There is no handshake — the sender simply fires packets at the destination. UDP provides no guarantee of delivery, no ordering, no duplicate detection, and no flow control. Each datagram is independent. This makes UDP extremely lightweight and fast, with a minimal 8-byte header.

The choice depends on requirements. TCP is right when data integrity is critical: HTTP, HTTPS, SSH, FTP, SMTP, and database connections. UDP is preferred when low latency matters more than perfect delivery: VoIP, video streaming, online gaming, DNS queries.

Modern protocols often build on UDP to get the best of both worlds. QUIC, which powers HTTP/3, runs over UDP but implements its own reliability and congestion control in user space, avoiding TCP's head-of-line blocking while still providing reliable delivery.

Question 4

What is the difference between HTTP and HTTPS?

Accepted Answer

HTTP (Hypertext Transfer Protocol) is the application-layer protocol for transferring web resources — HTML, JSON, images, etc. — between clients and servers. HTTPS is HTTP over TLS (Transport Layer Security). The 'S' stands for secure, and it adds three properties that plain HTTP lacks: confidentiality, integrity, and authentication.

Confidentiality: HTTP transmits everything in plaintext. An attacker who can observe network traffic (on a public Wi-Fi network, through a compromised router, or via ISP-level surveillance) sees headers, cookies, session tokens, and body content verbatim. TLS encrypts the connection with symmetric AES keys established during the handshake, so intercepted traffic is ciphertext.

Integrity: without TLS, an attacker with network access can modify responses in transit — injecting ads into web pages, modifying JavaScript, or changing form data. This is an active man-in-the-middle attack. TLS uses message authentication codes (AES-GCM in TLS 1.3) that detect any modification to the ciphertext.

Authentication: HTTP has no mechanism to verify you're talking to the intended server. HTTPS uses X.509 certificates issued by trusted Certificate Authorities to bind a domain name to a public key. Your browser verifies the certificate chain, ensuring you've reached the actual server and not an impersonator.

Practical implications: cookies sent over HTTP are trivially stolen by anyone on the same network. The `Secure` cookie flag prevents a cookie from being sent over non-HTTPS connections. The `HSTS` (HTTP Strict Transport Security) header instructs browsers to always use HTTPS for a domain, preventing protocol downgrade attacks.

HTTPS adds latency: the TLS handshake requires 1-2 round trips before data flows (TLS 1.3 reduced this to 1 RTT, with 0-RTT resumption for returning visitors). In practice this overhead is small compared to DNS lookup and TCP handshake latency, and HTTPS enables HTTP/2 (which browsers only allow over TLS), which more than compensates through multiplexing and header compression.

HTTPS is now the baseline — browsers flag plain HTTP sites as 'Not Secure', Let's Encrypt provides free certificates, and Google's ranking algorithm favors HTTPS.

Question 5

What are WebSockets and when would you use them instead of HTTP?

Accepted Answer

WebSockets are a protocol (RFC 6455) that provides full-duplex, persistent communication over a single TCP connection. Unlike HTTP's request-response model, where the client initiates every exchange, a WebSocket connection allows both the client and server to send messages independently at any time after the connection is established.

Establishment uses an HTTP upgrade handshake: the client sends an HTTP GET with `Upgrade: websocket` and `Connection: Upgrade` headers plus a `Sec-WebSocket-Key`. The server responds with 101 Switching Protocols and a `Sec-WebSocket-Accept` header derived from the key. After this, the connection switches from HTTP framing to the WebSocket binary framing protocol on the same underlying TCP socket. This design means WebSockets work through existing HTTP infrastructure (proxies, load balancers, firewalls) on ports 80 and 443.

The wire format is frame-based: frames have an opcode (text, binary, ping, pong, close), payload length, and optional masking (client-to-server frames are always masked to prevent cache poisoning attacks on intermediaries). Messages can span multiple frames (fragmentation).

When to use WebSockets over HTTP: real-time bidirectional use cases where the server needs to push data without the client polling. Classic examples: live chat, collaborative editing (Google Docs-style), multiplayer games, live trading/financial data feeds, live sports scores, and collaborative code editors. Also appropriate when you need low latency and high frequency updates — WebSocket message overhead is much lower than HTTP headers on every message.

When not to use WebSockets: simple request-response APIs, infrequent updates where Server-Sent Events (SSE) or long polling suffice, scenarios requiring stateless horizontal scaling (WebSocket connections are stateful and sticky), or when HTTP/2 server push covers the use case.

Scaling WebSocket servers requires sticky sessions (connections must reach the same server instance) or a pub-sub broker (Redis, Kafka) that routes messages to whichever server instance holds a given connection. This adds operational complexity versus stateless HTTP services.

In Python, `websockets` or `fastapi`/`starlette` WebSocket support is common. In Node.js, `ws` or `socket.io` (which adds fallbacks and rooms). `socket.io` is not WebSockets — it has its own protocol with polling fallback and higher-level abstractions.

Question 6

What is the difference between REST and gRPC?

Accepted Answer

REST (Representational State Transfer) and gRPC are both approaches for building networked APIs, but they make fundamentally different tradeoffs optimized for different contexts.

REST is an architectural style built on HTTP semantics: resources are identified by URLs, operations are expressed with HTTP verbs (GET, POST, PUT, DELETE, PATCH), and representations are typically JSON or XML. REST is stateless, cacheable (GET responses can be cached at HTTP layer), and leverages existing HTTP infrastructure. Its strength is interoperability and accessibility: any client that speaks HTTP can call a REST API without a generated client — browsers, curl, Python's requests, all work natively. REST APIs are self-documenting through URL structure and HTTP conventions, and humans can understand and debug them with basic tools.

gRPC is a Remote Procedure Call framework from Google, built on HTTP/2 and Protocol Buffers (protobuf). Instead of resources and verbs, you define services and methods in a `.proto` schema file. protoc generates strongly typed client and server stubs in your target language. Messages are binary-encoded (not human-readable text), making them ~5-7x smaller than equivalent JSON and faster to serialize/deserialize. HTTP/2 enables multiplexed streams over one connection, bidirectional streaming, and header compression.

The four communication patterns gRPC supports that REST doesn't match natively: unary RPC (one request, one response — REST equivalent), server streaming (one request, stream of responses — REST needs SSE/chunked), client streaming (stream of requests, one response), and bidirectional streaming (both sides stream independently — no REST equivalent without WebSockets).

When to choose REST: public-facing APIs where clients are diverse and unknown, APIs that benefit from HTTP caching, web browser clients (gRPC-Web exists but adds complexity), when developer experience and discoverability matter more than raw performance.

When to choose gRPC: internal service-to-service communication in microservices architectures, high-throughput low-latency APIs (real-time systems, ML inference), when you need strong typing and generated clients to reduce integration bugs across team boundaries, or when you need streaming.

Contract enforcement is a key gRPC advantage: the .proto file is a formal contract. Breaking changes are caught at code generation time. REST with OpenAPI approximates this, but JSON's dynamic nature means runtime type errors are more common.

Question 7

What are the 7 OSI layers and what does each do?

Accepted Answer

The OSI (Open Systems Interconnection) model is a conceptual framework that divides network communication into 7 ordered layers, each providing services to the layer above and consuming services from the layer below. While real protocols (TCP/IP) don't map cleanly onto OSI, the model remains the standard reference for discussing network behavior.

**Layer 1 — Physical**: Transmits raw bits over a physical medium (copper, fiber, radio). Defines electrical signals, cable specs, pin layouts. Examples: Ethernet physical layer, USB, Wi-Fi radio.

**Layer 2 — Data Link**: Frames bits into data units, handles node-to-node delivery on a single network segment. Provides MAC addressing and error detection (CRC). Examples: Ethernet (MAC frames), Wi-Fi (802.11), ARP. Switches operate here.

**Layer 3 — Network**: Routes packets across multiple networks using logical (IP) addresses. Handles path selection and packet forwarding. Examples: IP (v4/v6), ICMP, routing protocols (OSPF, BGP). Routers operate here.

**Layer 4 — Transport**: Provides end-to-end communication between processes. TCP gives reliable, ordered, connection-oriented delivery with flow control and congestion control. UDP gives unreliable, connectionless, low-latency delivery. Port numbers live here—they identify the receiving process.

**Layer 5 — Session**: Manages sessions between applications—establishing, maintaining, and terminating dialogues. Handles session recovery after interruptions. In practice, this layer is mostly subsumed by Layer 7 protocols or TLS. Examples: NetBIOS, RPC session management.

**Layer 6 — Presentation**: Translates data between network format and application format: character encoding (UTF-8 vs. ASCII), encryption/decryption, compression. TLS encryption is sometimes placed here. In practice, often merged with Layer 7.

**Layer 7 — Application**: The topmost layer—the protocol the application directly uses. Examples: HTTP, HTTPS, DNS, SMTP, FTP, WebSocket.

The practical interview framing: when debugging network issues, OSI layers guide troubleshooting from physical connectivity up. 'Is it a Layer 3 problem (routing)? Layer 4 (port blocked by firewall)? Layer 7 (application misconfiguration)?' Load balancers operating at Layer 4 route by IP/port; Layer 7 load balancers inspect HTTP headers for smarter routing.

Question 8

What is CORS and how does the preflight request work?

Accepted Answer

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls whether JavaScript running on one origin (scheme + host + port) can make HTTP requests to a different origin. Without CORS, the Same-Origin Policy would block all such requests entirely.

The browser enforces CORS — servers and network intermediaries cannot. When JavaScript calls `fetch('https://api.example.com/data')` from `https://app.example.com`, the browser checks whether the response includes `Access-Control-Allow-Origin: https://app.example.com` (or `*`). If not, the browser blocks the JavaScript from reading the response, even though the HTTP request was sent and the server responded normally.

**Simple vs. non-simple requests:**
Simple requests (GET/HEAD/POST with only safe headers and `application/x-www-form-urlencoded`, `multipart/form-data`, or `text/plain` content types) skip the preflight. The browser sends the request directly with an `Origin` header and validates the response headers.

Non-simple requests — PUT, DELETE, PATCH, any request with custom headers (`Authorization`, `Content-Type: application/json`), or requests with credentials — trigger a **preflight**.

**Preflight request flow:**
1. Browser sends an `OPTIONS` request to the same URL with headers:
   - `Origin: https://app.example.com`
   - `Access-Control-Request-Method: POST`
   - `Access-Control-Request-Headers: Authorization, Content-Type`
2. Server responds (if it allows the request):
   - `Access-Control-Allow-Origin: https://app.example.com`
   - `Access-Control-Allow-Methods: POST, PUT, DELETE`
   - `Access-Control-Allow-Headers: Authorization, Content-Type`
   - `Access-Control-Max-Age: 86400` (cache preflight for 24h)
3. If the preflight succeeds, the browser sends the actual request. If it fails (missing or mismatched headers), the browser blocks the request without sending it.

**Credentials** (`withCredentials: true` / cookies): the server must respond with `Access-Control-Allow-Credentials: true` and must NOT use `Access-Control-Allow-Origin: *` — it must specify the exact origin.

Common production issues: forgetting to handle `OPTIONS` in server routing (returning 404 or 405), not including custom headers in `Access-Control-Allow-Headers`, or using a wildcard origin with credentials. `Access-Control-Max-Age` is often overlooked — without it, browsers send a preflight on every non-simple request, doubling latency.

Question 9

What are the key differences between HTTP/1.1, HTTP/2, and HTTP/3?

Accepted Answer

HTTP has evolved through three major versions, each addressing the performance limitations of its predecessor.

**HTTP/1.1** (1997) is text-based and sequential. Each request-response pair uses a TCP connection, and without pipelining (which was poorly implemented), only one request can be in-flight per connection. Browsers work around this by opening 6-8 parallel TCP connections per origin, but each connection incurs its own TCP handshake and TLS negotiation overhead. Head-of-line (HOL) blocking is a fundamental problem: a slow response on connection 1 blocks all subsequent requests on that connection.

**HTTP/2** (2015) is binary and multiplexed. Key improvements:
- **Binary framing**: data is split into binary frames rather than text, enabling efficient parsing and mixing of frames from multiple streams on a single TCP connection.
- **Multiplexing**: multiple request/response streams share a single TCP connection. A slow response does not block other streams — eliminating HTTP-level HOL blocking and removing the need for multiple parallel connections.
- **Header compression (HPACK)**: HTTP headers are compressed using a shared dynamic table, reducing overhead significantly for repetitive headers (cookies, authorization).
- **Server push**: the server can proactively send resources (CSS, JS) before the client requests them.

HTTP/2 still suffers from **TCP-level HOL blocking**: a single lost TCP packet blocks all multiplexed HTTP/2 streams until the packet is retransmitted, because TCP delivers bytes in order.

**HTTP/3** (2022) replaces TCP with **QUIC** (Quick UDP Internet Connections) built on UDP. Key improvements:
- **No TCP HOL blocking**: QUIC tracks streams independently. A lost packet only blocks the stream it belongs to, not all streams.
- **0-RTT and 1-RTT connection establishment**: QUIC combines the transport and TLS 1.3 handshakes. Returning users can send data with 0 round trips (0-RTT), vs. 3+ round trips for a new TCP+TLS 1.2 connection.
- **Connection migration**: QUIC connections are identified by a connection ID, not a 4-tuple (src IP, src port, dst IP, dst port). Mobile clients moving between Wi-Fi and cellular maintain their connections without re-establishing.
- **Improved congestion control**: QUIC implements congestion control in user space, enabling faster iteration and per-stream flow control.

In practice: HTTP/2 is now universal for HTTPS. HTTP/3 is supported by ~30% of web traffic (all major CDNs). The performance gains from HTTP/3 are most pronounced on lossy networks (mobile, high-latency connections).

Question 10

What is the structure of an HTTP request?

Accepted Answer

An HTTP/1.1 request is a plaintext message with four structural parts:

**1. Request line** — the first line containing three space-separated tokens: the HTTP method (GET, POST, PUT, DELETE, PATCH, etc.), the request target (path and query string, e.g., `/api/users?page=2`), and the HTTP version (`HTTP/1.1`). Example: `GET /api/users?page=2 HTTP/1.1`

**2. Headers** — a sequence of `Name: Value` lines, each terminated by CRLF. Headers carry metadata: `Host` (required in HTTP/1.1 and identifies the virtual host), `Content-Type` (media type of the body), `Content-Length` (byte count of body), `Authorization` (credentials, typically `Bearer <token>`), `Accept` (desired response format), `Cookie`, and many others. Header names are case-insensitive.

**3. Blank line** — a single CRLF sequence that separates headers from the body. This delimiter is mandatory regardless of whether a body is present.

**4. Body (optional)** — the request payload. For GET and HEAD requests, the body is conventionally empty. For POST and PUT, it carries the data being sent. The `Content-Type` header declares how to parse it: `application/json`, `application/x-www-form-urlencoded`, `multipart/form-data` (file uploads), etc.

**HTTP/2 differences**: HTTP/2 is binary, not text. It multiplexes requests over a single TCP connection using frames and streams, with header compression (HPACK). The conceptual structure (method, headers, body) is the same but the wire format is entirely different.

**Security relevance**: sensitive data must never go in the URL (it ends up in server logs and browser history). Credentials belong in the `Authorization` header or the body over HTTPS. Query strings are acceptable for filtering and pagination.

Knowing the structure matters for debugging — tools like curl -v, Wireshark, and browser DevTools all expose this raw format.

Question 11

What are the main HTTP status code categories and key codes?

Accepted Answer

HTTP status codes are three-digit integers grouped into five classes by their leading digit. Understanding the distinction between classes, and the semantics of individual codes, is essential for building correct APIs and debugging client-server interactions.

**1xx Informational** codes indicate a provisional response. The most common is `101 Switching Protocols`, returned when a server agrees to upgrade to WebSocket.

**2xx Success** codes confirm the request was received, understood, and accepted. `200 OK` is the general success response for GET and POST. `201 Created` signals that the request resulted in a new resource; the `Location` header should point to it. `204 No Content` confirms success with no body—used for DELETE or PATCH when nothing needs to be returned. `206 Partial Content` is returned for range requests (e.g., video streaming).

**3xx Redirection** codes require the client to take additional action. `301 Moved Permanently` and `302 Found` are the classic redirects; browsers cache 301 permanently, making it hard to revert. `304 Not Modified` is returned on conditional GET when the cached copy is still fresh—it carries no body, saving bandwidth. `307` and `308` are the method-preserving equivalents of 302 and 301 respectively: the HTTP method must not change during the redirect.

**4xx Client Error** codes indicate the request was malformed or unauthorized. `400 Bad Request` is a generic parse/validation failure. `401 Unauthorized` means authentication is required or failed—despite the name, it is about authentication, not authorization. `403 Forbidden` means authenticated but not permitted. `404 Not Found` means the resource does not exist at that URI. `409 Conflict` signals a state conflict (e.g., duplicate resource). `422 Unprocessable Entity` is preferred for semantic validation failures in REST APIs. `429 Too Many Requests` signals rate limiting.

**5xx Server Error** codes indicate the server failed to fulfil a valid request. `500 Internal Server Error` is the generic catch-all. `502 Bad Gateway` means an upstream proxy received an invalid response. `503 Service Unavailable` means the server is temporarily overloaded or in maintenance—should include a `Retry-After` header. `504 Gateway Timeout` means the upstream did not respond in time.

Question 12

Which HTTP methods are idempotent and why does it matter?

Accepted Answer

An HTTP method is **idempotent** if making the same request N times produces the same server state as making it once. It is **safe** if it does not modify server state at all. These properties are not just academic—they directly determine whether a client or proxy can safely retry a request after a network failure.

**Safe methods**: GET, HEAD, OPTIONS, TRACE. Because they have no side effects, they can be retried, cached, and prefetched without concern.

**Idempotent but not safe**: PUT, DELETE. PUT replaces a resource with the supplied representation; sending it twice results in the same final state as sending it once. DELETE removes a resource; a second DELETE on an already-deleted resource should return 404 or 204, but the server state is the same (resource absent). These cannot be cached but can be retried safely on timeout.

**Neither idempotent nor safe**: POST, PATCH. POST typically appends or creates a new resource—sending it twice creates two resources. PATCH applies a partial update; the semantics depend on the operation (an increment patch is not idempotent, a set patch could be). Clients must not auto-retry POST without idempotency keys.

**Why it matters in practice**: Load balancers and service meshes use idempotency to decide retry policy. A timed-out GET can be retried immediately; a timed-out POST cannot without risking duplicate processing (double charges, duplicate orders). This is why payment APIs like Stripe require an `Idempotency-Key` header on POST requests—it allows safe retries by making POST behave as idempotent at the application layer.

Distributed systems also rely on this property for at-least-once delivery. Message consumers processing HTTP callbacks must treat POST payloads as potentially duplicated and implement deduplication logic (storing processed IDs) when the operation is not naturally idempotent.

A common confusion is between idempotency and the HTTP response code: a second DELETE returning 404 instead of 204 does not violate idempotency—idempotency is about server state, not response equality.

Question 13

What are the differences between GraphQL and REST?

Accepted Answer

REST and GraphQL are both API paradigms, but they optimise for different constraints. The right choice depends on client diversity, data shape variability, team structure, and caching requirements.

**Data fetching model**: REST organises resources at fixed URLs; a client fetches `/users/1` and `/users/1/orders` in two round trips. GraphQL exposes a single endpoint where the client specifies exactly which fields it needs in one query, eliminating over-fetching (receiving unused fields) and under-fetching (needing multiple requests). This is the primary driver for GraphQL adoption in mobile clients where bandwidth and latency are constrained.

**Schema and type system**: GraphQL has a mandatory, strongly-typed schema (SDL) that serves as a contract between client and server. Introspection lets tooling auto-generate documentation, type-safe clients, and mocks. REST has no built-in schema standard, though OpenAPI/Swagger fills this gap. The GraphQL schema makes breaking changes visible immediately and enables powerful developer tooling (GraphiQL, code generators).

**Versioning**: REST APIs typically version via URL (`/v2/`) or headers. GraphQL avoids versioning by evolving the schema additively—new fields are added, old ones deprecated. This requires careful schema governance but eliminates the maintenance burden of parallel API versions.

**Caching**: REST maps naturally to HTTP caching—GET requests are cacheable by URL at CDN and browser layers with no extra work. GraphQL queries are typically POST requests to a single URL, which breaks HTTP caching. Per-query caching requires either query hashing, persisted queries, or application-layer caches (DataLoader, Redis). This is a meaningful operational complexity cost.

**N+1 problem**: GraphQL's flexible resolution model can trigger N+1 database queries (one query per list item for a nested field). The standard mitigation is the DataLoader pattern—batching and deduplicating resolver calls within a single request.

**When to choose each**: REST is simpler, benefits from HTTP caching natively, and is well-understood by every HTTP toolchain. Choose GraphQL when you have multiple clients (web, mobile, third-party) with divergent data requirements, or when reducing mobile round trips is a priority. Many organisations use REST for public APIs (cacheability, simplicity) and GraphQL for internal/BFF (Backend-for-Frontend) layers.

Networking Interview Questions — What Senior Engineers Need to Know

All 13 Questions

How to Prepare

Related Topics

Test Your Knowledge