Cursor or offset pagination?

Offset (?page=2&limit=20) is simple and allows jumping to any page, but it drifts when rows are inserted and gets slow on deep pages. Cursor pagination (?after= ) is stable under inserts and fast at any depth, which is why feeds use it. Offset is fine for admin tables with page numbers.

How do you handle autocomplete race conditions?

Three standard fixes: abort the previous request with AbortController, tag each request with a sequence number and ignore responses older than the latest, or use a data library that keys results by query so a stale response cannot overwrite a newer key. Aborting plus key-based caching is the usual answer.

Debounce or throttle?

Debounce waits for a pause: use it for search input where only the final value matters. Throttle guarantees a maximum rate: use it for scroll, resize, and mousemove where you want steady updates. Autocomplete typically debounces at 250–300ms.

Which requests are safe to retry?

Idempotent ones: GET, PUT, and DELETE can be retried safely. POST needs an idempotency key so the server can deduplicate. Retry only on network errors, 408, 429, and 5xx, with exponential backoff plus jitter, and always cap total attempts and total time.

How should APIs be versioned?

URL versioning (/v1/orders) is the most visible and cache-friendly. Header versioning keeps URLs stable but is easy to forget. Additive, non-breaking evolution is best of all: add fields, never repurpose them, and deprecate with a sunset header and a migration window.

API Design & Data Fetching

API contracts plus the resilience layer: retries, timeouts, cancellation, and races.

Module 9 · API Design & Data Fetching

REST vs GraphQL, API versioning, offset vs cursor pagination, retries with backoff, timeouts, request cancellation, debouncing, throttling, polling, and race-condition handling.

REST resource design, GraphQL trade-offs, versioning and idempotency, offset vs cursor pagination, then the client resilience layer: retries with backoff, timeouts, cancellation, debouncing, throttling, polling, and race-condition handling.

About this module

Every frontend system design answer eventually reaches the API layer. Interviewers want contract literacy plus resilience: what the endpoint looks like, and what your UI does when it is slow, flaky, or answers out of order.

This module covers REST resource design, GraphQL trade-offs, versioning strategies, idempotency, and the two pagination models, then moves into the client patterns that actually break in production.

You will learn retry with exponential backoff and jitter, timeout budgets, AbortController-based cancellation, debounce vs throttle, polling vs push, and the three standard fixes for autocomplete race conditions.

The canonical drill is Google-style search autocomplete: input → debounce → request → cache → results, with stale responses discarded rather than rendered.

Phase 4 (Week 4) of the interview roadmap. Senior Track spans modules 1–19; the Staff Track starts at module 20.

Why this matters

Every frontend system design answer reaches the API layer. Interviewers want the contract and the failure story: what the endpoint looks like, what happens on a 500, what happens when three autocomplete responses come back out of order, and how you avoid rendering stale data.

Key topics covered

REST Resource Design
GraphQL Trade-offs
API Versioning
Idempotency
Offset vs Cursor Pagination
Error Contracts
Retries & Backoff
Timeout Budgets
Request Cancellation
Debouncing & Throttling
Polling Strategies
Race Conditions
Autocomplete Case Study

Where you'll use it

Designing the API contract for a paginated feed
Building autocomplete that never renders a stale response
Retrying a flaky mutation without double-charging a customer
Cancelling in-flight requests when a user navigates away
Choosing polling intervals versus pushing over SSE

The API Layer

Every system design answer ends up here. Bring the contract and the failure story.

Frontend engineers are not asked to design databases, but they are expected to be fluent in API contracts and, more importantly, in what the UI does when those contracts fail to deliver: slow responses, partial failures, duplicates, and answers that arrive in the wrong order.

Contract: resources, verbs, pagination, versioning, error shape
Resilience: retries, timeouts, cancellation, backoff, circuit breaking
Rate control: debounce, throttle, request coalescing, polling cadence
Correctness: idempotency keys and race-condition handling

How to open the answer

Sketch the endpoints first, then say: “Now let me cover what happens when this is slow or fails.” Interviewers rarely have to prompt for the second half, which is exactly why volunteering it scores.

REST Resource Design

Nouns for resources, verbs for intent, status codes that mean something.

HTTP methods and their semantics
Method	Semantics	Idempotent	Typical success
GET	Read, no side effects	Yes	200
POST	Create or invoke	No	201 / 202
PUT	Replace whole resource	Yes	200 / 204
PATCH	Partial update	Not inherently	200
DELETE	Remove resource	Yes	204

Plural resource paths: /orders, /orders/{id}, /orders/{id}/items
Filtering, sorting, and paging belong in the query string, not the path
Avoid verbs in paths; /orders/{id}/cancel is acceptable for true actions
Return the created resource on POST so the client avoids a second round trip
Design for the screen: a chatty API forces waterfalls the UI cannot hide

GraphQL Trade-offs

Solves over-fetching and waterfalls. Moves the cost elsewhere.

REST versus GraphQL trade-offs
Dimension	REST	GraphQL
Shape control	Server decides	Client decides
Round trips	Often several	Usually one
HTTP caching	Native, per-URL	Weak; needs client cache
Versioning	Explicit versions	Additive + deprecation
Failure mode	Whole request fails	Partial data + errors[]
Main risk	Over/under-fetching	Expensive nested queries

The answer interviewers want

GraphQL earns its complexity when many clients need different shapes of deeply related data. For a single product surface with stable screens, REST plus a well-designed aggregate endpoint is usually simpler and caches better at the CDN.

API Versioning

Clients you cannot force-update are the whole reason versioning exists.

API versioning strategies
Strategy	Example	Trade-off
URL path	/v2/orders	Visible, CDN-cacheable, but forks routes
Header	Accept: application/vnd.api.v2+json	Clean URLs, easy to forget, harder to cache
Query param	/orders?version=2	Simple, but pollutes cache keys
Additive evolution	New optional fields only	No version at all; requires discipline

Additive changes (new optional fields) are not breaking: never repurpose an existing field
Breaking changes need a new version plus a documented sunset window
Announce deprecation with a Deprecation and Sunset header so clients can log warnings
Web clients update fast; mobile clients can sit on an old version for a year — plan for that

Idempotency

The reason you can safely retry a payment.

An operation is idempotent when performing it twice has the same effect as performing it once. GET, PUT, and DELETE are idempotent by definition. POST is not, which is why blind retries on POST can double-charge a customer.

// The client generates the key once, then reuses it for every retry.
const idempotencyKey = crypto.randomUUID();

await fetch("/v1/payments", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Idempotency-Key": idempotencyKey,
  },
  body: JSON.stringify({ orderId, amountCents }),
});

Key detail candidates miss

The key must be generated once per logical operation, not per attempt. Generating a fresh UUID inside the retry loop defeats the entire mechanism.

Offset vs Cursor Pagination

Feeds use cursors. Admin tables use offsets. Know why.

Offset versus cursor pagination
Aspect	Offset	Cursor
Shape	?page=3&limit=20	?after=eyJpZCI6...&limit=20
Jump to page N	Yes	No
Stable under inserts	No: items shift and duplicate	Yes
Deep-page cost	Grows with offset	Constant
Total count	Easy	Expensive or omitted
Best for	Admin tables, search results	Feeds, chat, activity logs

// Cursor response: the client never computes the next position itself.
{
  "items": [ /* ... */ ],
  "pageInfo": {
    "nextCursor": "eyJpZCI6MTIzLCJ0cyI6MTcwMH0",
    "hasNextPage": true
  }
}

The drifting feed problem

On an offset-paginated feed, three new posts arriving between page 1 and page 2 push three items you already saw onto page 2. Users see duplicates and silently miss others. Cursors anchor to a position in the data, so inserts cannot shift the window.

Error Contracts

A consistent error shape is what lets the UI respond intelligently.

Use a stable machine-readable code; never parse human-readable messages
Distinguish retryable (5xx, 429, network) from terminal (4xx) failures
Return field-level errors for form validation, keyed by field name
Include a correlation id so a user-reported bug maps to a server trace
fetch() does not reject on 4xx/5xx: check response.ok explicitly

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests.",
    "retryable": true,
    "retryAfterMs": 2000,
    "correlationId": "b3f1c9e2-..."
  }
}

Retries & Backoff

Retry the right things, back off exponentially, and always add jitter.

Which responses are safe to retry
Condition	Retry?
Network error / DNS failure	Yes
408 Request Timeout	Yes
429 Too Many Requests	Yes, honour Retry-After
500, 502, 503, 504	Yes
400, 404, 422 (bad input)	No
401 / 403	No: refresh auth or stop

async function withRetry<T>(fn: () => Promise<T>, attempts = 3): Promise<T> {
  let lastError: unknown;

  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (error) {
      lastError = error;
      if (!isRetryable(error) || i === attempts - 1) break;

      // Exponential backoff with full jitter: 0–200ms, 0–400ms, 0–800ms.
      const ceiling = 200 * 2 ** i;
      await new Promise((r) => setTimeout(r, Math.random() * ceiling));
    }
  }

  throw lastError;
}

Why jitter is non-negotiable

Without jitter, every client that failed at the same moment retries at the same moment. The recovering server is hit by a synchronized thundering herd and falls over again.

Timeout Budgets

A request with no timeout is a spinner with no end.

fetch has no default timeout: without AbortSignal.timeout it can hang indefinitely
Budget per interaction, not per request: 3s total beats 3 × 3s sequential
Retries must fit inside the budget: attempts × (timeout + backoff) ≤ budget
Show a slow-request affordance before the timeout fires, not after
Background prefetches deserve shorter budgets than user-initiated actions

const res = await fetch("/v1/search?q=" + encodeURIComponent(q), {
  signal: AbortSignal.timeout(3000),
});

if (!res.ok) throw new ApiError(res.status);

Request Cancellation

AbortController is the single most useful API in this chapter.

Cancel on unmount so a resolved response never sets state on a dead component
Cancel the previous request whenever a new one supersedes it
AbortSignal.any([userSignal, AbortSignal.timeout(3000)]) combines reasons
Aborting rejects with an AbortError: filter it out of error UI
Cancellation is a client concern: the server may still complete the work

useEffect(() => {
  const controller = new AbortController();

  fetchResults(query, { signal: controller.signal })
    .then(setResults)
    .catch((e) => {
      if (e.name !== "AbortError") setError(e);
    });

  return () => controller.abort();
}, [query]);

Debouncing & Throttling

Same goal, opposite guarantees.

Debounce versus throttle
	Debounce	Throttle
Fires	Once, after a pause	At most once per interval
Guarantee	Only the final value	Steady stream of updates
Use for	Search input, autosave, resize-end	Scroll, mousemove, progress
Typical delay	250–300ms	100–200ms
Risk	Feels laggy if too long	Still fires during idle bursts

Related lever: coalescing

Deduplicate identical in-flight requests by returning the same promise to every caller. Ten components asking for the same user profile should produce one network request, not ten.

Polling Strategies

Simple, cheap, and often the right answer before you reach for sockets.

Fixed interval: predictable, but wasteful when nothing changes
Adaptive interval: speed up on change, back off when idle
Pause polling when the tab is hidden (visibilitychange) and resume on focus
Use ETag / If-None-Match so unchanged data returns a cheap 304
Escalate to SSE or WebSockets only when latency requirements justify it

// Adaptive polling: fast while active, slow when nothing is happening.
let delay = 2000;

async function tick() {
  const changed = await pollOnce();
  delay = changed ? 2000 : Math.min(delay * 2, 60_000);
  if (document.visibilityState === "visible") setTimeout(tick, delay);
}

Race Conditions

Responses do not arrive in the order you sent them.

You type sho then shoes. The second request is served from a warm cache and returns in 40ms; the first hits a cold path and returns in 400ms. Without protection, the UI shows results for sho under the text shoes.

Three standard race-condition fixes
Fix	How it works	Note
Abort previous	Cancel the in-flight request on each new input	Cleanest; also saves bandwidth
Sequence guard	Ignore any response older than the latest id	Works when abort is unavailable
Key by input	Cache results per query string	Stale response lands under its own key

// Sequence guard: cheap, framework-free, and easy to explain on a whiteboard.
const latest = useRef(0);

async function search(q: string) {
  const id = ++latest.current;
  const data = await fetchResults(q);
  if (id === latest.current) setResults(data); // else: stale, drop it
}

Case Study: Autocomplete

The most-asked frontend design question, end to end.

Input
  ↓  local state updates immediately (never block typing)
Debounce 250ms
  ↓  skip queries under 2 characters
Cache lookup
  ↓  hit → render instantly, no network
Request (AbortController + 3s timeout)
  ↓  previous request aborted
Response
  ↓  discard if not the latest sequence
Render + keyboard nav (↑ ↓ Enter Esc, aria-activedescendant)

Minimum query length avoids a request per single character
Cache by normalized query: trimmed, lowercased, collapsed whitespace
Keep the previous list visible while refetching to avoid flicker
Announce result counts to screen readers via an aria-live region
Handle the empty state and the error state explicitly, not as a blank dropdown

Scaling follow-up

When asked to scale it: prefix results are highly cacheable at the CDN, popular prefixes can be precomputed, and the long tail can fall back to the search service. Mention short TTLs so trending queries stay fresh.

Interview Takeaways

What to say when the design reaches the API layer.

Present the contract, then volunteer the failure story
Cursor pagination for feeds; offset only where page numbers matter
Retry only retryable statuses, with exponential backoff plus jitter
POST retries need an idempotency key generated once per operation
Every request gets a timeout and an AbortSignal
Name all three race-condition fixes: abort, sequence guard, key by input
Debounce waits for a pause; throttle caps the rate

Frequently Asked Questions

API design and data fetching interview questions.

Method

Semantics

Idempotent

Typical success

GET

Read, no side effects

Yes

200

POST

Create or invoke

201 / 202

PUT

Replace whole resource

Yes

200 / 204

PATCH

Partial update

Not inherently

200

DELETE

Remove resource

Yes

204

Dimension

REST

GraphQL

Shape control

Server decides

Client decides

Round trips

Often several

Usually one

HTTP caching

Native, per-URL

Weak; needs client cache

Versioning

Explicit versions

Additive + deprecation

Failure mode

Whole request fails

Partial data + errors[]

Main risk

Over/under-fetching

Expensive nested queries

Strategy

Example

Trade-off

URL path

/v2/orders

Visible, CDN-cacheable, but forks routes

Header

Accept: application/vnd.api.v2+json

Clean URLs, easy to forget, harder to cache

Query param

/orders?version=2

Simple, but pollutes cache keys

Additive evolution

New optional fields only

No version at all; requires discipline

// The client generates the key once, then reuses it for every retry. const idempotencyKey = crypto.randomUUID(); await fetch("/v1/payments", { method: "POST", headers: { "Content-Type": "application/json", "Idempotency-Key": idempotencyKey, }, body: JSON.stringify({ orderId, amountCents }), });

Aspect

Offset

Cursor

Shape

?page=3&limit=20

?after=eyJpZCI6...&limit=20

Jump to page N

Yes

Stable under inserts

No: items shift and duplicate

Yes

Deep-page cost

Grows with offset

Constant

Total count

Easy

Expensive or omitted

Best for

Admin tables, search results

Feeds, chat, activity logs

Condition

Retry?

Network error / DNS failure

Yes

408 Request Timeout

Yes

429 Too Many Requests

Yes, honour Retry-After

500, 502, 503, 504

Yes

400, 404, 422 (bad input)

401 / 403

No: refresh auth or stop

async function withRetry<T>(fn: () => Promise<T>, attempts = 3): Promise<T> { let lastError: unknown; for (let i = 0; i < attempts; i++) { try { return await fn(); } catch (error) { lastError = error; if (!isRetryable(error) || i === attempts - 1) break; // Exponential backoff with full jitter: 0–200ms, 0–400ms, 0–800ms. const ceiling = 200 * 2 ** i; await new Promise((r) => setTimeout(r, Math.random() * ceiling)); } } throw lastError; }

useEffect(() => { const controller = new AbortController(); fetchResults(query, { signal: controller.signal }) .then(setResults) .catch((e) => { if (e.name !== "AbortError") setError(e); }); return () => controller.abort(); }, [query]);

Debounce

Throttle

Fires

Once, after a pause

At most once per interval

Guarantee

Only the final value

Steady stream of updates

Use for

Search input, autosave, resize-end

Scroll, mousemove, progress

Typical delay

250–300ms

100–200ms

Risk

Feels laggy if too long

Still fires during idle bursts

// Adaptive polling: fast while active, slow when nothing is happening. let delay = 2000; async function tick() { const changed = await pollOnce(); delay = changed ? 2000 : Math.min(delay * 2, 60_000); if (document.visibilityState === "visible") setTimeout(tick, delay); }

Fix

How it works

Note

Abort previous

Cancel the in-flight request on each new input

Cleanest; also saves bandwidth

Sequence guard

Ignore any response older than the latest id

Works when abort is unavailable

Key by input

Cache results per query string

Stale response lands under its own key

// Sequence guard: cheap, framework-free, and easy to explain on a whiteboard. const latest = useRef(0); async function search(q: string) { const id = ++latest.current; const data = await fetchResults(q); if (id === latest.current) setResults(data); // else: stale, drop it }

Input ↓ local state updates immediately (never block typing) Debounce 250ms ↓ skip queries under 2 characters Cache lookup ↓ hit → render instantly, no network Request (AbortController + 3s timeout) ↓ previous request aborted Response ↓ discard if not the latest sequence Render + keyboard nav (↑ ↓ Enter Esc, aria-activedescendant)

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

The API Layer

How to open the answer

REST Resource Design

GraphQL Trade-offs

The answer interviewers want

API Versioning

Idempotency

Key detail candidates miss

Offset vs Cursor Pagination

The drifting feed problem

Error Contracts

Retries & Backoff

Why jitter is non-negotiable

Timeout Budgets

Request Cancellation

Debouncing & Throttling

Related lever: coalescing

Polling Strategies

Race Conditions

Case Study: Autocomplete

Scaling follow-up

Interview Takeaways

Frequently Asked Questions

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

The API Layer

How to open the answer

REST Resource Design

GraphQL Trade-offs

The answer interviewers want

API Versioning

Idempotency

Key detail candidates miss

Offset vs Cursor Pagination

The drifting feed problem

Error Contracts

Retries & Backoff

Why jitter is non-negotiable

Timeout Budgets

Request Cancellation

Debouncing & Throttling

Related lever: coalescing

Polling Strategies

Race Conditions

Case Study: Autocomplete

Scaling follow-up

Interview Takeaways

Frequently Asked Questions