The web request
What does a backend developer do?
A backend developer builds the server-side part of a product: the code that receives requests, applies business rules, reads and writes data, and talks to other services. The browser or app is the client; the backend answers it. Good answers mention correctness, performance, security and operability, not only endpoints.
Why it is asked: it opens the round and shows whether you see the whole system. Read the full explanation: how the system design round works.
What happens when you type a web address and press Enter?
The browser looks up the server's address through the Domain Name System, opens a Transmission Control Protocol connection, usually wraps it in Transport Layer Security (TLS), and sends a Hypertext Transfer Protocol (HTTP) request. The server routes it to code, which may call a cache or database, and returns a status code, headers and a body that the browser renders.
Why it is asked: it tests breadth, and every layer invites a follow-up. Read the full explanation: representational state transfer (REST) API interview questions.
What do the HTTP status code classes mean?
HTTP defines five status classes: 1xx informational, 2xx success, 3xx redirection, 4xx client error and 5xx server error (Request for Comments (RFC) 9110 section 15, June 2022). The split matters for retries: the Amazon Web Services (AWS) Builders' Library article notes that client errors generally should not be retried, while server errors may succeed later (Brooker, December 2019). The exceptions are 429 Too Many Requests (RFC 6585, April 2012) and 503 Service Unavailable, which may carry a Retry-After header telling the client how long to wait before trying again.
Why it is asked: it links protocol detail to reliability behaviour. Read the full explanation: REST API interview questions.
APIs
What is the difference between a safe and an idempotent HTTP method?
A safe method has read-only semantics, and an idempotent method has the same intended effect on the server whether you send it once or many times. Request for Comments (RFC) 9110 defines GET, HEAD, OPTIONS and TRACE as safe, and PUT, DELETE and all safe methods as idempotent (RFC 9110, June 2022). POST is neither.
Why it is asked: it decides which requests a client may retry blindly. Read the full explanation: REST API interview questions.
How do you make a POST request safe to retry?
An idempotency key is a unique value the client generates and sends with a request so the server can recognise a repeat. In Stripe's version 1 API the server saves the status and body of the first request and returns that saved response for retries with the same key, and keys can be pruned after 24 hours (Stripe API reference).
Why it is asked: double-charging is the classic failure. Read the full explanation: design a payment system.
How do you paginate a large list, and why is offset pagination a trap?
Offset pagination asks for "skip N rows, return 20", so the database still walks the N skipped rows, and results shift if rows are inserted between requests. Cursor pagination returns a token for the last row seen and asks for rows after it, which stays fast and stable on an indexed sort key. Offsets are fine for small, static lists.
Why it is asked: it tests whether you think about cost at scale. Read the full explanation: offset or cursor pagination in REST API interview questions.
What is the N+1 query problem?
The N+1 problem is code that runs one query for a list and then one more query per item, so a page costs 1 + N round trips. In a test with 100 authors and their books, the loop issued 101 queries and a single join issued one.1 Fix it with a join, a batched IN query or eager loading.
Why it is asked: it is the most common hidden cost behind object-mapping libraries. Read the full explanation: the N+1 query problem in full-stack developer interview questions.
How would you version an API?
Prefer changes that do not break clients: add fields, never repurpose them. When a break is unavoidable, expose a new version in the path or a header, run both for a stated period, and tell consumers when the old one ends. Treat the contract as a promise to people who deploy on their own schedule.
Why it is asked: it reveals whether you have supported real consumers. Read the full explanation: REST API interview questions.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Caching
How does HTTP caching work?
A response carries headers that tell caches how long it stays fresh and when to revalidate. RFC 9111 says max-age marks a response stale after that many seconds; no-cache lets a cache store the response but requires validation before reuse; no-store tells caches not to store any part of the request or response (RFC 9111, June 2022).
Why it is asked: no-cache versus no-store is a common slip. Read the full explanation: ETags and conditional requests in REST API interview questions.
What is the cache-aside pattern, and what makes invalidation hard?
In cache-aside the application checks the cache first, reads the database on a miss, and writes the result into the cache. Invalidation is hard because the cache and database are two stores: if a write updates one and the other update fails or arrives late, readers see stale data. Short time-to-live values bound the damage.
Why it is asked: "there are two hard things" is a joke because it is true. Read the full explanation: design a distributed cache.
What is a cache stampede?
A stampede happens when a popular cache entry expires and many requests miss at once and all hit the database to rebuild it. Defences include a lock so one request rebuilds while others wait, serving slightly stale data during the rebuild, and adding random jitter to expiry times so entries do not expire together.
Why it is asked: it shows you can predict failure under load. Read the full explanation: design a distributed cache.
Reliability
Why does every remote call need a timeout?
Without a timeout, a slow dependency holds a thread, a connection and memory until it answers, and a few slow calls can exhaust the caller. The AWS article advises setting a timeout on every remote call, connection and request, chosen from the downstream service's latency percentile; too low a value triggers retries that flood the backend (Brooker, December 2019).
Why it is asked: unbounded waits cause most cascading outages. Related: how clients should retry without taking the service down.
How do you retry a failed request safely?
Retry only idempotent calls, only on errors that may succeed later, with exponential backoff and jitter, and with a small attempt limit. Exponential backoff waits longer after each failure: a 100-millisecond base doubling to a 5,000-millisecond cap gives 100, 200, 400, 800, 1,600, 3,200 and then 5,000.1 Jitter adds randomness so clients do not retry in step.
Why it is asked: retry logic is where well-meant code hurts. Related: retries and backoff in API design interview questions.
How can retries make an outage worse?
Retries multiply across layers. The AWS article describes a five-layer stack in which each layer tries a call three times, so a failing database sees 243 times the normal load, and recommends retrying at one point in the stack, which avoids the multiplication (Brooker, December 2019). That is three attempts per layer across five layers, 3^5 = 243. Counted as three retries on top of the first try, each layer makes four attempts and the figure is 4^5 = 1,024.1
Why it is asked: it tests systems thinking about feedback loops. Read the full explanation: design a distributed rate limiter and API gateway.
Text description of the diagram
- Three attempts per layer across five layers send 243 requests to the failing database.
- Retrying at only one point in the stack avoids the multiplication.
What does jitter do, and does it really matter?
Jitter is random variation added to a delay so many clients do not act at the same instant. In a seeded test of 1,000 clients that all failed together, a fixed 100-millisecond retry put all 1,000 requests into one 10-millisecond slot, while full jitter spread them so the busiest slot held 114.1
Why it is asked: it separates people who have seen a retry storm from people who have not. Related: how clients should retry without taking the service down.
How does rate limiting work?
A rate limiter caps how many requests a client can make in a period and rejects the excess, commonly with a 4xx status. A token bucket adds tokens at a steady rate up to a maximum; each request spends one, so short bursts pass but the average stays bounded. The AWS article uses a local token bucket to limit retries the same way.
Why it is asked: it protects shared capacity and is a frequent design prompt. Read the full explanation: design a distributed rate limiter and API gateway.
Security
What is the difference between authentication and authorisation?
Authentication establishes who the caller is; authorisation decides what that caller may do. They fail differently: the OWASP API Security Top 10 (2023) lists broken authentication second and three separate authorisation failures, at object, property and function level, first, third and fifth (OWASP, 2023).
Why it is asked: confusing the two is a red flag. Read the full explanation: REST API interview questions.
What is the most common API vulnerability?
OWASP ranks broken object-level authorisation first in its 2023 list: an endpoint takes an object identifier from the request and returns the object without checking that this caller owns it. The fix is a server-side ownership check on every access, not obscure identifiers.
Why it is asked: it tests whether you check permissions where the data is touched. Read the full explanation: broken object-level authorization in API design interview questions.
Operations and architecture
What does it mean for a backend service to be stateless?
A stateless service keeps no user session or request data in its own process between requests, so any instance can serve any request. The Twelve-Factor App says to run the app as one or more stateless processes that do not rely on local state (Twelve-Factor App). State lives in a database, cache or queue, which lets you add or remove instances freely.
Why it is asked: horizontal scaling depends on it. Read the full explanation: what stateless means in REST API interview questions.
Why use a message queue, and what is at-least-once delivery?
A queue lets a producer hand work to consumers asynchronously, so spikes are absorbed and a slow consumer does not block the caller. At-least-once delivery means a message may be delivered more than once, so consumers must be idempotent. Webhooks have the same property: senders retry, so receivers must tolerate repeats.
Why it is asked: it connects queues back to idempotency. Read the full explanation: webhooks explained.
How do you handle concurrent updates to the same record?
Pick the control that fits the conflict rate. Optimistic concurrency reads a version number and updates only if it is unchanged, retrying on conflict, which suits rare conflicts. Pessimistic locking holds a lock while working, which suits frequent conflicts but risks waits and deadlocks. Database transactions at a suitable isolation level cover multi-row changes.
Why it is asked: lost updates are quiet and expensive. Read the full explanation: concurrency interview questions.
How do you deploy a change without downtime?
Keep old and new versions compatible for a while: ship a backward-compatible database change first, roll out the new code gradually while the old instances still serve traffic, watch error rates, and keep a fast rollback. The Twelve-Factor App stresses fast startup and graceful shutdown so instances can be replaced safely.
Why it is asked: it tests release discipline, not just coding. Read the full explanation: rolling, blue-green and canary deployment strategies.
How do you debug a slow endpoint in production?
Measure before guessing. Check the latency percentile, not the average; trace one slow request through each hop; look at the database query plan and the count of queries per request; and compare with the last deploy. Twelve-Factor treats logs as event streams that a log router ships to an indexing system for search (Twelve-Factor App, XI. Logs); a distributed trace is a separate signal that follows one request across services.
Why it is asked: it reveals your method under uncertainty. Read the full explanation: database interview questions.
What backend interview questions should I ask the interviewer?
Ask how the team deploys and how often, what happens during an incident and who is on call, how failures are reviewed, how services are tested, and what the hardest recent scaling problem was. Specific questions show you have operated systems, and the answers tell you how the team really works.
Why it is asked: the interviewer is also judging your curiosity. Read the full explanation: how the system design round works.
- Safe means read-only and idempotent means repeat-proof; retry only idempotent calls.
- Give every remote call a timeout, and retry at one layer with backoff and jitter.
- Retries multiply across layers: three attempts per layer over five layers is 3^5 = 243 times the load.
- Authorise on the server for every object; authentication alone is not enough.
- Keep services stateless so any instance can serve any request, and ask questions back.
Sources
- RFC 9110: HTTP Semantics — IETF (STD 97; month only), 1 Jun 2022
- RFC 9111: HTTP Caching — IETF (month only), 1 Jun 2022
- Timeouts, retries, and backoff with jitter — Amazon Web Services Builders' Library (Marc Brooker), 5 Dec 2019
- Idempotent requests, Stripe API reference — Stripe (page undated; read 2026-10-24), 24 Oct 2026
- OWASP API Security Top 10, 2023 edition — OWASP API Security Project (page shows 2023 only), 1 Jan 2023
- RFC 6585: Additional HTTP Status Codes — IETF (month only), 1 Apr 2012
- The Twelve-Factor App, XI. Logs — Adam Wiggins (page last updated 2017), 1 Jan 2017
- The Twelve-Factor App — Adam Wiggins (page last updated 2017), 1 Jan 2017
