38 Backend & API interview questions with answers

All Backend & API interview questions

• What is an idempotency key and what retry problem does it solve?

  The problem: POST is not idempotent — if a client submits a create-order/payment and the network times out, it cannot tell whether the server received it. A blind retry → duplicates (double order, double charge). An idempotency key is a unique string (usually a UUID)…

• Offset vs cursor pagination — what is the difference and when to pick cursor?

  - Offset (LIMIT 20 OFFSET 40 / ?page=3): simple, jumps to any page, can show total page count. Two weaknesses: (1) slow on deep pages — the DB still scans and discards the first 40 rows; (2) result drift — if rows are inserted/deleted meanwhile,…

• What do "safe" and "idempotent" mean in HTTP? Which methods are which?

  Safe = the method is read-only and does not change server state (GET, HEAD, OPTIONS). Idempotent = calling it once or N times leaves the same state (GET, HEAD, PUT, DELETE, OPTIONS). Every safe method is idempotent; the converse is false. Method Safe Idempotent ---------…

• How does PUT differ from PATCH? What is the difference between JSON Merge Patch and JSON Patch?

  PUT replaces the whole resource with the body you send: any field missing from the body is treated as removed or reset to default. PATCH describes only the change. Two common PATCH formats: - JSON Merge Patch (application/merge-patch+json): the body mirrors the resource, and null…

• After creating a resource, which status do you return: 200, 201, 202, or 204? When do you need a Location header?

  Pick based on whether the work is finished and whether there is a body: - 201 Created — a new resource now exists. Include a Location header pointing at its URL; the body is usually the resource itself. - 200 OK — work finished and…

• When client input is wrong, do you return 400, 422, or 409? Distinguish the three.

  The three map to three different layers of failure: - 400 Bad Request — the request is syntactically wrong and the server cannot parse it: malformed JSON, badly formed headers. - 422 Unprocessable Content — syntax is fine and it parses, but the content is…

• How do you design an API error contract? What fields does RFC 9457 (problem+json) define?

  The principle: one error format across the whole API, machine-readable and debuggable. RFC 9457 standardizes exactly that, served as Content-Type: application/problem+json. Standard members: - type — a URI identifying the error class (clients match on this, not on the title string). - title — a…

• A user double-clicks Pay because the network is slow. How do you design the flow to avoid duplicate transactions?

  Use a client-generated idempotency key; the server remembers the outcome and replays it instead of reprocessing. The flow: 1. The client generates a unique key per payment intent (UUID v4, created when the checkout screen opens, reused across retries) and sends it in an Idempotency-Key…

• Should API versioning live in the URL or a header? When must you cut a new version, and how do you deprecate the old one?

  Two common approaches: - URL path (/v1/orders) — what the Google API design guide and most public APIs use. Visible, easy to route, cache, and split at the gateway. Downside: one resource ends up with several URIs. - Header (Accept: application/vnd.api+json; version=2, or a dedicated…

• Which rate-limiting algorithm do you use, and which headers must the server return so the client knows how long to wait?

  Algorithms, from simplest to most accurate: - Fixed window — count requests per minute. Simplest, but it has a boundary flaw: 100 requests at the end of minute 1 plus 100 at the start of minute 2 means 200 requests in two seconds, all legal.…

• A list endpoint needs filtering, sorting, and field selection. How do you design the query parameters cleanly and safely?

  Keep one convention across every collection endpoint rather than inventing a new shape per endpoint. - Filter: expose simple fields directly as query params (status=paid). For complex expressions use one filter param with a fixed grammar (filter=status=paid AND total100000), as the Google API design guide…

• A report-export endpoint takes 3 minutes and keeps timing out. How do you redesign it?

  Move from a synchronous request to an async job: accept the request, return immediately, process in the background, and let the client track the outcome. The client then tracks it one of two ways: Polling — GET /jobs/7c2 returns { "status": "running" "succeeded" "failed", "progress":…

• You need a bulk endpoint that updates 500 records. If 3 of them fail, what status code do you return?

  First agree on the semantics with the caller, because this is a business question more than an HTTP one: Option 1 — all-or-nothing (atomic). Run the whole batch in one transaction; a single bad record rolls everything back and returns 422 with the list of…

• For cursor pagination: what should the cursor contain, and what happens when rows are inserted or deleted while the client is paging?

• Two users edit the same record and the second one overwrites the first. How do ETag and If-Match solve this?

• How would you design a webhook delivery system for partners? How do you handle retries, signing, and replay protection?

• When a call to another service times out, how should the client retry? How do you pick the timeout?

• You must change a response schema without breaking old clients (a mobile app you cannot force-update). How do you do it, and how do you police breaking changes?

• Why does writing to the DB and then publishing a message cause data inconsistency? (the dual write problem)

  Because the DB and the message broker are two separate systems with no shared transaction. You write to both in one function, but nothing guarantees both succeed. Two failure directions: - DB committed, publish fails (broker down, process killed): the order exists in the DB…

• What does an idempotent consumer mean? How do you choose a dedup key?

  Idempotent means processing the same message multiple times yields the same result as processing it once. It is required because brokers deliver at-least-once: retries, rebalances, and lost acks all create duplicates. Common approach — record the handled message in the same transaction as the business…

• How should a consumer retry on failure? Why exponential backoff and jitter?

  Retrying immediately and without a limit is the fastest way to turn a small incident into a large one: the struggling downstream service receives the retry traffic on top of the original load. Exponential backoff — grow the wait geometrically (1s, 2s, 4s, 8s...) capped…

• What do you do when consumers are slower than producers for a sustained period?

  First separate two situations, because they are handled completely differently. Temporarily slow (a traffic spike) — the queue is the buffer, that is its job. You only need enough storage and monitoring to know when the backlog drains. Nothing else is required. Persistently slow (consumer…

• Kafka, RabbitMQ, or Redis Streams — for a given problem, which do you choose and why?

  Choose by how the data is consumed, not by popularity. Kafka — a distributed log where messages are retained by policy and consumers read by offset. Pick it when: - You need replay: a new service wants the history, or you must reprocess after fixing…

• How do you implement the transactional outbox in production — polling publisher or CDC?

• In a saga, how do you compensate when a later step fails? And what if the compensation itself fails?

• In a system that handles payments, what data type do you store money in? How do you deal with multiple currencies?

  Never use float/double for money. Binary floating point cannot represent 0.1 exactly, so summing many rows drifts by cents and breaks reconciliation. Two correct options: - Integer in the smallest unit: store amountminor BIGINT. VND has no decimal part, so 150000 = 150,000 VND; USD…

• How would you design role-based access control (RBAC) for a system with admins, staff, and customers?

  The minimal model is three tables — users, roles, permissions — plus two join tables, userroles and rolepermissions. Users get roles; roles bundle permissions shaped as verb + resource (order.read, order.refund, user.ban). Implementation rules: - Check on the server, on every request. Hiding a button…

• When calling a cross-origin API with `fetch` and `credentials: 'include'`, what must the server return?

  Once a request carries cookies cross-origin, the browser applies stricter rules. The server must return both headers: - Access-Control-Allow-Origin: https://app.example.com — it must be a concrete origin; is rejected. - Access-Control-Allow-Credentials: true. If a preflight is involved, the OPTIONS response must repeat both, and Access-Control-Allow-Headers…

• Between two services, should you use REST, gRPC, or a message queue? What drives the choice?

  The first question is not the protocol but: does the caller need the result before it can continue? Synchronous (REST / gRPC) — the result is required to proceed: checking stock before creating an order, validating a token. The price is that the caller depends…

• What belongs in an API gateway, and what must never be put there?

  The gateway is the single entry point for clients and handles cross-cutting concerns — things every service needs and should not reimplement ten times. Belongs there: - Routing requests to the right service; hiding internal topology from clients. - Authentication (validate the token, reject anonymous…

• What is a BFF (Backend for Frontend)? If you already have a gateway, why add one?

  A BFF is a backend dedicated to one client type (web, iOS/Android, internal console), owned by that frontend team, sitting between the client and the business services. The problem it solves: a single shared API is always wrong for someone. Mobile wants small payloads, fewer…

• You must change an API response that four other services consume — how do you avoid breaking them?

  Principle: backward-compatible changes need no new version; breaking changes require running two versions side by side for a while. Safe changes (add, never remove): new fields, new enum values with a default branch, new endpoints. This only holds if consumers are written as tolerant readers…

• If a project uses an ORM (Prisma/TypeORM/Hibernate), can it still be SQL-injected? Where are the gaps?

  Yes. An ORM is only safe in the statements it generates itself; anywhere you concatenate strings you are back to the original risk. Three common gaps: Raw queries with concatenation. The ORM escape hatches ($queryRawUnsafe, string-based createQuery, the driver's query()) do not parameterise for you.…

• An image-convert feature shells out to ImageMagick with a user-supplied filename. What is the risk and how would you rewrite it?

  The risk is command injection: once a string passes through a shell, characters like ;, , &&, $(...), and backticks are interpreted as new commands running with the application process's privileges. The rewrite — drop the shell: execFile/spawn (with shell: false, the default) hands the…

• The frontend already validates the form with Zod — does the backend need to validate again? How should server-side validation be done?

  Yes, and it is non-negotiable. Client validation is a user-experience feature, not a security control — the client is entirely under the user's control, and anyone can call the API directly with curl or Postman, bypassing the form completely. Server-side validation principles: - Allowlist, not…

• The `GET /users/:id` endpoint returns the raw ORM record. What is wrong with that, even if the UI never displays the extra fields?

  This is excessive data exposure: the API returns everything it has and lets the client pick what to render. But the client is not a hiding place — open the Network tab and the whole response is visible. Returning an ORM entity directly usually drags…

• How do SOAP and REST differ in nature, message format and how the API is described? When would a system still choose SOAP?

  SOAP is a protocol with a strict standard: every message is XML wrapped in an Envelope, and the API contract is described by a WSDL file. REST is an architectural style built on HTTP: everything is a resource with a URL, manipulated through HTTP methods…

• When designing a REST API, how do you name endpoints consistently: singular or plural nouns, nested resources, and non-CRUD actions such as "cancel an order"?

  The URL is a noun naming the resource; the HTTP method is the verb. Write GET /orders/42, not GET /getOrder?id=42. The conventions most teams use: - Plural nouns for collections: /users, /users/42. Use plural in both forms so nobody has to remember where it is…