Question 1

Design the endpoint and client flow for editing a record with an optimistic UI update, reconciling correctly when the server rejects the change.

Accepted Answer

The trick is to update the UI immediately as if the edit already succeeded, while keeping the previous value around so you can undo cleanly. You fire the PATCH request in the background; if it comes back 2xx, you swap the optimistic value for whatever the server actually returned (the server may normalize or recompute fields, so don't just trust your own optimistic copy as final). If it fails, you roll the field back to its previous value and surface an error — you never want the UI showing a state the server never actually held.

The part people miss is race protection: if the same field gets edited twice quickly, an older request's response can land after a newer one and stomp it. Tag each mutation with a monotonically increasing version per record and drop any response whose version isn't the latest you've sent.

```js
async function updateTitle(id, newTitle) {
  const prev = todos.find(t => t.id === id).title;
  const version = ++pendingVersion.current[id] || 1;
  setTodos(ts => ts.map(t => t.id === id ? { ...t, title: newTitle, _pending: true } : t));
  try {
    const res = await fetch(`/api/todos/${id}`, { method: 'PATCH', body: JSON.stringify({ title: newTitle }) });
    if (!res.ok) throw new Error('rejected');
    const saved = await res.json();
    if (version === pendingVersion.current[id]) {
      setTodos(ts => ts.map(t => t.id === id ? { ...saved, _pending: false } : t));
    }
  } catch {
    if (version === pendingVersion.current[id]) {
      setTodos(ts => ts.map(t => t.id === id ? { ...t, title: prev, _pending: false } : t));
      showToast('Update failed, reverted');
    }
  }
}
```

Question 2

Design a file-upload endpoint plus the frontend flow that shows progress and survives a mid-upload retry.

Accepted Answer

For progress, `XMLHttpRequest.upload.onprogress` (fetch's streaming upload progress support is inconsistent across browsers) gives you `loaded`/`total` bytes to drive a progress bar. That alone handles the happy path, but a single giant PUT/POST can't survive a dropped connection partway through — you'd have to restart from zero.

To survive a mid-upload failure, split the file into fixed-size chunks (e.g. 5MB) using `File.slice()`, upload each chunk tagged with its index and an uploadId, and let the server assemble them once all chunks arrive. The client tracks which chunk indices have been acknowledged; on retry (network drop, tab reload) it only re-sends the chunks that weren't confirmed, not the whole file.

```js
async function uploadFile(file, uploadId, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  for (let i = 0; i < totalChunks; i++) {
    if (confirmedChunks.has(i)) continue; // resume: skip already-acked chunks
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    const form = new FormData();
    form.append('chunk', chunk);
    form.append('index', i);
    form.append('uploadId', uploadId);
    await uploadWithProgress(form, (loaded) => updateProgress(i, loaded, chunkSize, totalChunks));
    confirmedChunks.add(i);
  }
  await fetch(`/api/uploads/${uploadId}/complete`, { method: 'POST' });
}
```

Server-side, it writes each chunk to a temp location keyed by `uploadId + index` and, on the `/complete` call, verifies all expected indices are present before concatenating.

Question 3

Model a nested comment thread in a document database and write the fetch logic that returns one post's full thread.

Accepted Answer

The simplest workable model is an adjacency list: every comment document stores `postId` and `parentId` (null for top-level). Writes are trivial — inserting a reply is just one document — but reading a whole thread means fetching everything for `postId` in one query and reconstructing the tree in application code, since document databases generally can't do recursive joins.

An alternative is a materialized path (each comment stores something like `path: "c1/c4/c9"`), which lets you fetch a subtree with a single prefix query, at the cost of needing to update descendants' paths if a comment ever gets moved — rare enough for comments that it's usually not worth the complexity.

```js
// one query: all comments for the post, flat
const flat = await db.collection('comments').where('postId', '==', postId).get();

Question 4

Given normalized users and posts tables, design the API response shape for a feed page and write the join/transform that produces it.

Accepted Answer

The API shouldn't leak the raw normalized table shape (a `userId` on every post that the client then has to resolve one-by-one) — that's the classic N+1 setup. Instead, the feed endpoint should return posts already denormalized with the author fields it needs, produced by a single join at query time rather than the client stitching users and posts together.

```sql
SELECT p.id, p.title, p.body, p.created_at,
       u.id AS author_id, u.name AS author_name, u.avatar_url AS author_avatar
FROM posts p
JOIN users u ON u.id = p.user_id
ORDER BY p.created_at DESC
LIMIT 20;
```

```js
const feed = rows.map(r => ({
  id: r.id,
  title: r.title,
  body: r.body,
  createdAt: r.created_at,
  author: { id: r.author_id, name: r.author_name, avatarUrl: r.author_avatar },
}));
```

One join plus one transform gives the client exactly the shape it renders, with zero follow-up requests per post.

Question 5

A long-running job exposes a status endpoint; implement client-side polling with backoff and clear stop conditions.

Accepted Answer

Poll `GET /jobs/:id/status` on an interval, but don't hammer the server at a fixed rate for a job that might take minutes — back off (e.g. double the delay up to a cap) as it keeps coming back `pending`. Stop polling the moment you hit a terminal status (`completed`/`failed`), on a max-attempts/overall-timeout, and always on component unmount so you don't leak a timer polling a screen nobody's looking at anymore.

```js
function usePollJob(jobId) {
  const [status, setStatus] = useState('pending');
  useEffect(() => {
    let delay = 1000, timer, cancelled = false;
    async function poll() {
      const res = await fetch(`/api/jobs/${jobId}/status`);
      const { status: s } = await res.json();
      if (cancelled) return;
      setStatus(s);
      if (s === 'pending' || s === 'running') {
        delay = Math.min(delay * 2, 15000);
        timer = setTimeout(poll, delay);
      }
    }
    poll();
    return () => { cancelled = true; clearTimeout(timer); };
  }, [jobId]);
  return status;
}
```

Question 6

A search box fires a request per keystroke; ensure only the latest response renders even when responses arrive out of order.

Accepted Answer

Two things solve this together. First, debounce keystrokes so you're not firing a request every character. Second — and this is the part that actually fixes out-of-order responses — cancel the previous in-flight request with `AbortController` when a new one starts, and/or tag each request with a sequence number and ignore any response that isn't from the most recent request you sent.

```js
function useSearch() {
  const [results, setResults] = useState([]);
  const controllerRef = useRef(null);
  const seqRef = useRef(0);

Example: type "reac" then quickly "react" — if the "reac" request is slower and returns after the "react" one, the sequence check drops it instead of overwriting the correct results on screen.

Question 7

Convert a nested server-side validation-error object into a flat list of {fieldPath, message} entries for form display.

Accepted Answer

Server validation errors often come back nested to mirror the request shape, e.g. `{ address: { city: ['required'], zip: ['invalid format'] } }`. A form component wants a flat list it can map straight onto individual fields, so you recursively walk the object, building up a dotted/bracketed path as you descend, and emit one entry per leaf message.

```js
function flattenErrors(obj, prefix = '') {
  const out = [];
  for (const [key, value] of Object.entries(obj)) {
    const path = prefix ? `${prefix}.${key}` : key;
    if (Array.isArray(value) && value.every(v => typeof v === 'string')) {
      value.forEach(message => out.push({ fieldPath: path, message }));
    } else if (value && typeof value === 'object') {
      out.push(...flattenErrors(value, path));
    } else if (typeof value === 'string') {
      out.push({ fieldPath: path, message: value });
    }
  }
  return out;
}
// flattenErrors({ address: { city: ['required'], zip: ['invalid format'] } })
// => [{ fieldPath: 'address.city', message: 'required' }, { fieldPath: 'address.zip', message: 'invalid format' }]
```

Question 8

Merge already-fetched pages of a paginated list into one de-duplicated, correctly ordered array after a refetch of page one.

Accepted Answer

This comes up whenever a list refreshes its first page (pull-to-refresh, a new item created, a sort change) while you already have pages 2, 3, etc. loaded in memory. You can't just prepend the new page-one items — an item might have moved pages, been deleted, or already exist further down — so you need to dedupe by id while letting the fresh page-one data win for anything it re-describes.

```js
function mergeAfterPageOneRefetch(existingItems, freshPageOne) {
  const freshIds = new Set(freshPageOne.map(i => i.id));
  const remainderNotInFreshPage = existingItems.filter(i => !freshIds.has(i.id));
  return [...freshPageOne, ...remainderNotInFreshPage];
}
```

Example: you had `[A, B, C, D, E]` loaded (pages 1–2, size 3 → really `[A,B,C]` + `[D,E]`), then page one refetches as `[F, A, B]` (F is new, C dropped off). Merging gives `[F, A, B, D, E]` — new item included, stale C removed, D/E preserved in their known order — instead of blindly gluing `[F,A,B]` onto the front and ending up with duplicate A/B or a stale C.

Question 9

Handle an incoming payment webhook: verify the signature, de-duplicate provider retries, and update the order state exactly once.

Accepted Answer

First, verify the request is genuinely from the payment provider by recomputing an HMAC over the *raw* request body using your shared webhook secret and comparing it to the signature header with a constant-time comparison — never trust the payload before this check passes, and never verify against a re-serialized JSON body, since re-encoding can change byte-for-byte content and break the signature.

Second, payment providers retry webhooks liberally (network blips, slow 2xx responses), so the same event id can arrive multiple times. Store processed event ids in a table/collection with a unique constraint on `eventId`, and only proceed with the order update if the insert succeeds — a duplicate insert failing is your de-dupe check, and it's safe under concurrent retries because the database enforces the uniqueness, not application logic.

```js
app.post('/webhooks/payment', rawBodyMiddleware, async (req, res) => {
  const signature = req.headers['x-provider-signature'];
  const expected = crypto.createHmac('sha256', WEBHOOK_SECRET).update(req.rawBody).digest('hex');
  if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return res.status(401).end();
  }
  const event = JSON.parse(req.rawBody);
  try {
    await db.collection('processedWebhookEvents').doc(event.id).create({ receivedAt: Date.now() }); // fails if it already exists
  } catch (e) {
    if (e.code === 'ALREADY_EXISTS') return res.status(200).end(); // already handled, ack and stop
    throw e;
  }
  await updateOrderStatus(event.data.orderId, event.data.status);
  res.status(200).end();
});
```

Question 10

Add caching to a read-heavy endpoint and invalidate it correctly when the underlying resource is updated through a separate write endpoint.

Accepted Answer

Cache the GET response (say `product:123`) in Redis with a TTL as a backstop against any invalidation you miss. The read path becomes: check cache, return it on a hit, otherwise query the DB and populate the cache before responding.

The invalidation part is the one people get wrong: on the write endpoint, after the DB write commits, *delete* the cache key rather than trying to update it in place. Deleting is safer because the write endpoint may not have (or compute) the exact same shape the read endpoint caches — recomputing on next read guarantees correctness, whereas writing a guessed value into the cache can leave it subtly stale or wrong.

```js
app.put('/products/:id', async (req, res) => {
  await db.products.update(req.params.id, req.body);
  await redis.del(`product:${req.params.id}`); // invalidate, don't try to patch the cached value
  res.sendStatus(204);
});

app.get('/products/:id', async (req, res) => {
  const key = `product:${req.params.id}`;
  const cached = await redis.get(key);
  if (cached) return res.json(JSON.parse(cached));
  const product = await db.products.findById(req.params.id);
  await redis.set(key, JSON.stringify(product), 'EX', 300);
  res.json(product);
});
```

Watch out for cache stampede: if the key expires under heavy traffic, many requests can miss simultaneously and all hit the DB at once — a short lock or jittered TTL keeps that from piling on.

Question 11

REST vs GraphQL — when would you actually pick one over the other?

Accepted Answer

REST gives you one URL per resource and lets you lean on HTTP semantics (verbs, status codes, caching via `Cache-Control`/ETags) for free. GraphQL gives the client one endpoint and lets it ask for exactly the fields it needs in one round trip, which is genuinely valuable when a screen needs data shaped from several unrelated resources (a dashboard combining user, orders, and notifications) — REST would mean either several requests or a bespoke aggregation endpoint per screen.

The tradeoff: GraphQL pushes query complexity (and the N+1 risk under nested resolvers) onto the server, and HTTP-level caching mostly stops working since everything goes through POST to one endpoint. A mobile app with tight bandwidth and many different, evolving screens is a good GraphQL fit; a small CRUD API with a handful of stable resources is usually simpler and cheaper to just build as REST.

Question 12

Why must PUT be idempotent but POST doesn't have to be, and what does that mean in practice for your API design?

Accepted Answer

Idempotent means calling it once has the same effect as calling it five times. `PUT /users/42` with the same body always leaves user 42 in the same final state no matter how many times it's retried — that's why HTTP defines it as idempotent, and clients/proxies are allowed to safely retry a PUT that timed out. `POST /orders`, by contrast, typically means "create a new thing," so retrying it naively creates duplicate orders — that's not a bug in POST, it's just not idempotent by definition.

In practice this matters most for retries after network failures: if your client retries a POST because it didn't get a response, you can end up double-charging a customer. That's why idempotency keys exist for POST endpoints that need retry-safety — the client generates a unique key per logical operation, and the server checks it before processing so a retried request with the same key gets the same result instead of a duplicate side effect.

Question 13

What's the practical difference between JWT-based auth and traditional session-based auth?

Accepted Answer

Session auth stores a session id in a cookie, and the server looks it up in a store (Redis, a DB table) on every request to know who's making it — the server owns the source of truth, so revoking a session is just deleting that row. JWT auth instead issues a signed token containing the user's claims directly; the server verifies the signature and trusts the contents without a lookup, which scales better across stateless servers but means you can't cheaply revoke a single token before it expires — it's valid until it expires, full stop, unless you maintain a blocklist (which brings back the same lookup cost you were trying to avoid).

A common real setup uses both: a short-lived JWT access token (5–15 minutes) for stateless API auth, plus a longer-lived refresh token stored server-side that can be revoked, so a compromised access token only has a small window of damage.

Question 14

What is CORS, and what actually happens during a preflight request?

Accepted Answer

CORS is a browser-enforced rule that stops a page loaded from `https://app.example.com` from silently reading responses from `https://api.other.com` unless that API explicitly allows it — it protects the *user*, not the server, from a malicious page making authenticated requests on their behalf and reading the results.

For "simple" requests (GET, or POST with a plain content-type) the browser just sends the request and checks the `Access-Control-Allow-Origin` header on the response. For anything riskier — a custom header, `Content-Type: application/json`, or methods like PUT/DELETE — the browser first sends an `OPTIONS` preflight request asking "am I allowed to actually do this?" The server must answer with the allowed origin, methods, and headers before the browser sends the real request at all. This is why adding a custom header to an API call can suddenly require CORS config you didn't need before — you crossed the line into needing a preflight.

Question 15

SQL vs NoSQL — how do you actually decide which to use for a given feature?

Accepted Answer

The real question isn't "which is better" but "how does my access pattern look, and how much do I need enforced structure and multi-record consistency." A relational DB (Postgres, MySQL) shines when your data has real relationships you'll query across (orders joined to users joined to products) and you need transactions that touch multiple rows atomically — an e-commerce checkout is the classic case. A document store (MongoDB, Firestore) shines when your data is naturally self-contained per document and your access pattern is mostly "fetch this whole thing by id" — a user profile with embedded preferences, or a chat message with its attachments.

In practice, plenty of real systems use both: Postgres for the core transactional data (accounts, billing) and a document store or cache for read-heavy, loosely-structured data (activity feeds, session data). Picking NoSQL purely for perceived scale when your data is actually relational tends to just push the joins into slower, error-prone application code.

Question 16

What does ACID mean for a database transaction, and why does it matter for something like a money transfer?

Accepted Answer

Atomicity means the whole transaction succeeds or none of it does — no half-applied state. Consistency means it moves the database from one valid state to another according to its constraints. Isolation means concurrent transactions don't see each other's uncommitted intermediate state. Durability means once committed, it survives a crash.

A bank transfer is the textbook example: debiting account A and crediting account B has to be one atomic transaction. If you debit A, the server crashes, and the credit to B never happens, atomicity is what guarantees the whole operation rolls back instead of leaving money vanished. Without isolation, a concurrent balance check could read A's balance mid-transfer and see money that's technically in transit, showing a wrong total.

```sql
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'A';
UPDATE accounts SET balance = balance + 100 WHERE id = 'B';
COMMIT; -- if anything fails before this, ROLLBACK undoes both updates
```

Question 17

What is the N+1 query problem, and how do you actually fix it?

Accepted Answer

It happens when you fetch a list (1 query) and then, for each item in that list, run another query to get related data — so fetching 50 posts with their authors turns into 1 query for the posts plus 50 more, one per post, for each author. It's easy to introduce accidentally with an ORM's lazy-loading relations, since `post.author.name` looks harmless in a loop but silently fires a query every iteration.

The fix is to fetch the related data in one batched query instead: either an explicit SQL join, or an ORM's eager-loading feature (`.include()`/`.populate()`), or — for GraphQL resolvers specifically — a DataLoader that batches and dedupes all the `author(id)` lookups requested during one tick into a single `WHERE id IN (...)` query.

```js
// N+1: one query per post
for (const post of posts) { post.author = await db.users.findById(post.userId); }

// fixed: one batched query for all authors
const userIds = [...new Set(posts.map(p => p.userId))];
const users = await db.users.findAll({ where: { id: userIds } });
const byId = new Map(users.map(u => [u.id, u]));
for (const post of posts) { post.author = byId.get(post.userId); }
```

Question 18

Monolith vs microservices — what are the actual tradeoffs, not just the buzzwords?

Accepted Answer

A monolith is one deployable codebase and one database (usually) — a function call is just a function call, a transaction spans your whole domain for free, and debugging means reading one stack trace. The cost shows up as it grows: build times climb, teams start stepping on each other's code, and you can't scale or deploy one hot part independently of the rest.

Microservices split that into independently deployable services, so a team can ship the payments service without touching search, and you can scale just the service that's actually under load. The cost is real: a "transaction" across two services is no longer atomic (you need sagas or eventual consistency), a request now involves network calls that can partially fail, and you need real infrastructure for service discovery, tracing, and versioned contracts between services — overhead that's wasted on a team of five with modest traffic.

The practical default: start as a well-modularized monolith (clean internal boundaries, no messy cross-cutting state), and split out a specific service only when you have a concrete scaling or team-ownership reason to — not preemptively.

Question 19

How does a CDN actually make a website faster?

Accepted Answer

A CDN caches your static assets (images, JS/CSS bundles, sometimes whole HTML pages) on servers physically distributed around the world, so a user in Mumbai gets the file from a nearby edge server instead of round-tripping to your origin server in, say, Virginia. That cuts both network latency and the load on your origin server, since most requests never reach it at all.

Example: without a CDN, every visitor loads your 2MB hero image from one origin server, and a traffic spike (a viral post) can saturate that server's bandwidth. With a CDN, that image gets cached at dozens of edge locations after the first request from each region, so the origin only ever serves it once per region until the cache expires.

Question 20

WebSockets vs Server-Sent Events vs long polling — how do you choose for a live-updating feature?

Accepted Answer

Long polling is the crudest: the client sends a request, the server holds it open until there's new data (or a timeout), then the client immediately reopens it. It works everywhere but adds latency and connection overhead per cycle.

Server-Sent Events (SSE) give you a real one-way push channel over plain HTTP — the server streams events to the client over a single long-lived connection, with automatic browser reconnection built in. It's a great fit for things like a live activity feed or notification stream where the server needs to push updates but the client never needs to send anything back over that same channel.

WebSockets give you a full-duplex connection — either side can send at any time — which is what you actually need for something interactive like a chat app or a collaborative cursor, where the client is also constantly sending. The cost is more infrastructure complexity: WebSocket connections are stateful, so scaling behind a load balancer needs sticky sessions or a shared pub/sub layer (Redis) so a message from one server reaches a client connected to a different server.

Question 21

Explain the token bucket algorithm for rate limiting and why you'd choose it over a fixed window counter.

Accepted Answer

A fixed window counter (e.g. "max 100 requests per minute") resets the count to zero exactly on the minute boundary, which lets a client burst 100 requests in the last second of one window and another 100 in the first second of the next — 200 requests in two seconds, technically within the rule. Token bucket avoids that: a bucket holds a fixed capacity of tokens, refills at a steady rate (say 1 token every 600ms for 100/min), and every request consumes one token; if the bucket's empty, the request is rejected or delayed. It naturally allows short legitimate bursts (using up saved tokens) while capping sustained throughput.

```js
class TokenBucket {
  constructor(capacity, refillPerMs) {
    this.capacity = capacity; this.tokens = capacity;
    this.refillPerMs = refillPerMs; this.last = Date.now();
  }
  tryConsume() {
    const now = Date.now();
    this.tokens = Math.min(this.capacity, this.tokens + (now - this.last) * this.refillPerMs);
    this.last = now;
    if (this.tokens >= 1) { this.tokens -= 1; return true; }
    return false;
  }
}
```

Question 22

What is CSRF and how do modern apps actually prevent it?

Accepted Answer

CSRF exploits the fact that a browser automatically attaches cookies to any request to a site, even one triggered from a totally different page. If your bank's "transfer money" endpoint trusts the session cookie alone, a malicious page can silently submit a form to that endpoint, and the browser happily attaches your logged-in session cookie — the bank sees what looks like a legitimate request from you.

The standard fix is a CSRF token: the server embeds a random, unpredictable token in the page (or a cookie plus a matching header), and requires the client to send it back on every state-changing request as a separate value the attacker's page has no way to read or guess (same-origin policy blocks reading another site's response). A modern, simpler alternative for many apps is setting the session cookie with `SameSite=Strict` or `Lax`, which stops the browser from sending it on cross-site requests in the first place — though CSRF tokens are still the more robust, defense-in-depth option for sensitive actions.

Question 23

How should you store user passwords, and what's actually wrong with just hashing them with SHA-256?

Accepted Answer

You store a salted hash produced by a slow, purpose-built algorithm like bcrypt or argon2 — never the plaintext, and never a fast general-purpose hash like SHA-256 or MD5. SHA-256 is deliberately fast (that's the whole point of a cryptographic hash for things like file checksums), which is exactly wrong for passwords: an attacker with a stolen hash database can try billions of guesses per second on cheap hardware, or just look the hash up in a precomputed rainbow table if there's no salt.

bcrypt/argon2 build in a per-password random salt (so two users with the same password get different hashes) and a tunable "cost factor" that deliberately makes each hash computation take, say, 100ms — cheap enough for your login flow to check once per attempt, but expensive enough that brute-forcing billions of guesses becomes impractical.

```js
const hash = await bcrypt.hash(plainPassword, 12); // store this, cost factor 12
const ok = await bcrypt.compare(attempt, hash); // on login
```

Question 24

What is a database index, how does it speed things up, and when can adding one actually hurt?

Accepted Answer

Without an index, looking up rows by a column means scanning every row (a full table scan) — fine for a 500-row table, terrible for a 50-million-row one. An index (typically a B-tree) maintains a sorted structure mapping column values to row locations, so a lookup becomes a fast tree traversal instead of a linear scan — the same reason a book's index beats reading every page to find a topic.

The catch: every index has to be updated on every INSERT/UPDATE/DELETE that touches its column, so adding indexes to a write-heavy table slows down writes and adds storage overhead — an index isn't free, it's a read/write tradeoff. Indexing every column "just in case" on a table that's written far more than it's read (an event log, an audit trail) can measurably hurt write throughput for query patterns nobody actually uses.

```sql
CREATE INDEX idx_orders_user_id ON orders(user_id); -- speeds up WHERE user_id = ?, costs a bit on every insert
```

Question 25

What's the difference between scaling horizontally and vertically?

Accepted Answer

Vertical scaling means making one machine bigger — more CPU, more RAM, a faster disk. It's simple (no architecture changes needed) but has a hard ceiling (there's a biggest machine you can buy) and a single point of failure. Horizontal scaling means adding more machines and spreading the load across them, which scales further and survives one machine dying, but requires your application to actually support running multiple instances — no in-memory state that only one instance knows about, a shared session store instead of local memory, a load balancer in front.

Example: a Node.js API server hitting CPU limits can either move to a bigger VM (vertical, quick fix) or run 5 smaller instances behind a load balancer (horizontal, more resilient, needs the app to be stateless first).

Question 26

What does a load balancer do, and what's the difference between round-robin and least-connections balancing?

Accepted Answer

A load balancer sits in front of multiple application servers and decides which one handles each incoming request, so no single server gets overwhelmed and the rest can absorb the load if one instance goes down (it also stops sending traffic to an instance failing its health check).

Round-robin just cycles through servers in order — server 1, 2, 3, 1, 2, 3 — regardless of how busy each currently is; it's simple and works fine when requests are roughly uniform in cost. Least-connections instead routes each new request to whichever server currently has the fewest active connections, which handles uneven request costs better — if one server is stuck processing a few slow requests, round-robin would still send it a share of new traffic, while least-connections routes around it until it frees up.

Question 27

How do you run a database schema migration safely against a production table with live traffic and no downtime?

Accepted Answer

The core rule is: never make a migration that requires the old code and the new code to disagree about the schema at the same instant, because during a rolling deploy both versions run simultaneously. The safe pattern is expand-and-contract: first add the new column/table as nullable/optional (old code ignores it, doesn't break); deploy new code that writes to both the old and new shape; backfill existing rows; deploy code that reads from the new shape only; and only once nothing references the old column do you drop it, in a separate, later migration.

Example: renaming `users.name` to `users.full_name` directly would break old server instances still selecting `name` mid-deploy. Instead: add `full_name` (step 1), deploy code writing to both columns (step 2), backfill `full_name` from `name` for existing rows (step 3), deploy code reading only `full_name` (step 4), then drop `name` once you're confident nothing needs it (step 5, later).

Also avoid long table locks: an `ALTER TABLE ADD COLUMN` with a default value used to rewrite the whole table in older Postgres versions — always check whether your migration tool/DB version does this instantly (metadata-only) or blocks the table for its duration.

Question 28

What do you actually gain and lose by using an ORM instead of writing raw SQL?

Accepted Answer

An ORM (Prisma, Sequelize, TypeORM) lets you work with objects/models instead of hand-writing SQL strings, gives you migrations, and protects you from SQL injection by parameterizing queries automatically. For straightforward CRUD it's genuinely faster to write and easier to keep consistent across a team.

What you lose is fine-grained control: a complex reporting query with multiple joins, window functions, or a query you need to tune for a specific index can be awkward or inefficient to express through an ORM's query builder, and ORMs are exactly where the N+1 problem sneaks in via lazy-loaded relations. Most real projects use the ORM for the 90% of queries that are simple CRUD, and drop to raw SQL (most ORMs support this escape hatch) for the handful of genuinely complex or performance-critical queries.

Question 29

SSR vs CSR vs SSG — what's the actual difference and when does each make sense?

Accepted Answer

CSR (client-side rendering) ships a near-empty HTML shell and a JS bundle; the browser downloads it, runs the JS, fetches data, and renders — great for highly interactive apps behind a login (a dashboard), but the user sees a blank page until JS loads and runs, and there's nothing for a crawler to read without executing JS.

SSR (server-side rendering) renders the full HTML on the server for each request, so the user (and search crawlers) get real content immediately, then JS "hydrates" it to make it interactive. It's better for SEO and perceived load time, at the cost of server compute per request.

SSG (static site generation) renders the HTML once at build time and serves the same static file to everyone — fastest possible response since there's no per-request work at all, ideal for content that doesn't change per-user (a blog, a marketing site), but wrong for anything genuinely personalized per request without extra client-side fetching on top.

Question 30

What is hydration in an SSR framework, and what goes wrong when it fails?

Accepted Answer

Hydration is the step where the browser takes the server-rendered static HTML and attaches React's (or another framework's) event listeners and internal state to it, turning static markup into an interactive app — without hydration, the buttons on that server-rendered page are just inert HTML.

It goes wrong when the client's first render produces different markup than what the server sent — a "hydration mismatch." A classic cause is rendering something time-dependent or environment-dependent server-side (`new Date().toLocaleString()`, or `if (typeof window !== 'undefined')` branches) that produces a different result in the browser than it did on the server. React detects the mismatch, throws a warning, and in the worst case discards the server-rendered DOM and re-renders from scratch client-side — losing the whole performance benefit SSR was supposed to give you, and sometimes causing a visible flash of different content.

Question 31

What is code splitting / lazy loading in a frontend app, and how do you implement it in React?

Accepted Answer

Instead of shipping one giant JS bundle with every route and component the app could ever need, code splitting breaks the bundle into chunks that load on demand — a user landing on the homepage doesn't need to download the admin panel's code until they actually navigate there. This directly cuts initial load time, especially on slow connections. ```jsx import { lazy, Suspense } from 'react'; const AdminPanel = lazy(() => import('./AdminPanel')); function App() { return ( }> } /> ); } ``` `React.lazy` plus a bundler that supports dynamic `import()` (Vite, Webpack) automatically splits `AdminPanel` into its own chunk, fetched only when that route is actually visited.

Question 32

Debounce vs throttle — what's the difference and when do you use each?

Accepted Answer

Debounce delays running a function until a burst of calls stops for a given quiet period — every new call resets the timer. It's right for something like a search-as-you-type box: you only want to fire the API call once the user pauses typing, not on every keystroke.

Throttle instead guarantees the function runs at most once every N milliseconds no matter how often it's called, without waiting for things to go quiet. It's right for something like a scroll or resize handler, where you want regular updates *while* the event keeps firing, not just once it stops.

```js
function debounce(fn, ms) {
  let t;
  return (...args) => { clearTimeout(t); t = setTimeout(() => fn(...args), ms); };
}
function throttle(fn, ms) {
  let last = 0;
  return (...args) => { const now = Date.now(); if (now - last >= ms) { last = now; fn(...args); } };
}
```

Question 33

Explain the JavaScript event loop, and the difference between the microtask and macrotask queues.

Accepted Answer

JS runs on a single thread with a call stack, and the event loop is what lets it handle async work without blocking: when the call stack is empty, the event loop pulls the next task from a queue and runs it. Macrotasks (setTimeout callbacks, I/O callbacks, UI events) are handled one at a time, with the browser potentially doing a render between them. Microtasks (Promise `.then`/`.catch`, `queueMicrotask`) run in a separate queue that gets fully drained after the current synchronous code finishes and before the next macrotask runs — so all pending promise callbacks always execute before the next `setTimeout`, even a `setTimeout(fn, 0)`.

```js
console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
// output: 1, 4, 3, 2 — sync code first, then the microtask queue fully drains, then the macrotask
```

Question 34

What problem does the virtual DOM actually solve, and how does it make UI updates faster?

Accepted Answer

Directly manipulating the real DOM is expensive — every change can trigger layout recalculation and repaint. React's virtual DOM is a lightweight in-memory tree representing what the UI should look like; when state changes, React builds a new virtual tree, diffs it against the previous one, and computes the minimal set of real DOM operations needed to reconcile the difference — rather than re-rendering everything from scratch on every change.

Example: if a list of 1000 items re-renders because one item's text changed, React's diffing figures out that only that one DOM text node needs updating, and leaves the other 999 DOM nodes completely untouched — avoiding 999 unnecessary, expensive DOM writes.

Question 35

What is database connection pooling, and why does opening a fresh connection per request cause problems at scale?

Accepted Answer

Opening a raw TCP connection to a database, doing the auth handshake, and tearing it down again is genuinely expensive — often tens of milliseconds — and every database has a hard cap on how many concurrent connections it can hold open (often in the low hundreds). If every incoming request opens its own connection, you can exhaust that cap under moderate traffic and start getting "too many connections" errors, on top of paying the connection-setup cost on every single request.

A connection pool solves this by keeping a fixed number of connections open and reusing them: a request borrows a connection from the pool, runs its query, and returns it — no new TCP handshake needed. It also acts as a natural backpressure valve: if all pool connections are busy, new requests queue briefly rather than the database getting hit with an unbounded number of simultaneous connections.

```js
const pool = new Pool({ max: 20, idleTimeoutMillis: 30000 }); // 20 reusable connections shared across all requests
const { rows } = await pool.query('SELECT * FROM users WHERE id = $1', [id]);
```

Question 36

When would you reach for a message queue (like SQS or RabbitMQ) instead of just calling a service directly?

Accepted Answer

A direct call couples the caller to the callee being available and fast right now — if you call an email-sending service synchronously during a signup request and that service is slow or down, your signup request fails or hangs with it. A queue decouples them: the signup handler just drops a "send welcome email" message onto the queue and returns immediately, and a separate worker processes messages whenever it can, retrying automatically on failure without the original request needing to know or wait.

Queues are also the right tool for smoothing out bursty load — if 10,000 users sign up in a spike, you don't want 10,000 simultaneous emails hitting your email provider's rate limit; a queue lets workers drain it at a steady, controlled pace instead. The tradeoff is added complexity (you now have an async system to monitor — dead-letter queues for failed messages, worker scaling, message ordering guarantees to think about) and the caller no longer gets an immediate success/failure result, only "accepted for processing."

Question 37

Explain the CAP theorem in practical terms — what does it actually force you to give up?

Accepted Answer

CAP says that when a network partition happens (some nodes in your distributed system can't talk to others — and in the real world, partitions *will* happen eventually), you have to choose between Consistency (every node sees the same, most recent data) and Availability (every request gets a response, even if it might be stale) — you can't have both during that partition. You always have Partition tolerance as a fact of distributed life, so CAP in practice is really a CP-vs-AP choice.

A CP system (e.g. a strongly-consistent config store like etcd/Zookeeper) will refuse to answer a request rather than risk returning stale or conflicting data during a partition — correctness over uptime. An AP system (e.g. DynamoDB's default mode, or Cassandra) keeps answering requests during a partition even if that means two nodes might briefly disagree, resolving the conflict later — uptime over strict correctness.

Example: a shopping cart service usually chooses AP — it's better to let a user add an item during a network blip (and reconcile duplicates later) than to show them an error page. A bank ledger balance check usually leans CP — showing a stale balance that's wrong is worse than a brief unavailability.

Question 38

What is database replication, and what problems does read-replica lag actually cause in an application?

Accepted Answer

Replication keeps copies of your database (replicas) in sync with the primary, usually so you can spread read traffic across multiple replicas while writes still go to the single primary — this both scales read throughput and gives you a failover target if the primary goes down. Most setups use asynchronous replication, meaning the primary commits a write and returns success before the replicas have necessarily applied it yet — there's a small, variable delay ("replication lag") before a replica reflects the latest write.

The classic bug this causes: a user submits a form (write goes to the primary), the app immediately redirects to a page that reads from a replica to show the result, and the replica hasn't caught up yet — the user sees their own just-submitted data missing or stale, which looks like data loss even though nothing was actually lost.

The common fix is "read-your-own-writes" routing: right after a write, route that specific user's subsequent reads to the primary (or a replica you've confirmed has caught up) for some short window, instead of blindly load-balancing every read across replicas.

Question 39

Optimistic locking vs pessimistic locking — what's the difference, and when does optimistic locking actually fail?

Accepted Answer

Pessimistic locking grabs a lock on a row before reading it (`SELECT ... FOR UPDATE`), so no other transaction can touch it until you're done — safe, but it means concurrent requests queue up waiting for the lock, which hurts throughput under contention. Optimistic locking assumes conflicts are rare: you read a row along with its version number, do your work without locking anything, and on write you check the version hasn't changed since you read it (`WHERE id = ? AND version = ?`); if zero rows were affected, someone else updated it first, and you retry or fail.

```sql
UPDATE inventory SET quantity = quantity - 1, version = version + 1
WHERE id = 42 AND version = 7; -- 0 rows affected = someone else updated it first, retry
```

Optimistic locking fails you when contention is actually high and conflicts are common — e.g. thousands of users trying to buy the last unit of a flash-sale item at the same second. There, most requests keep losing the version race and retrying, which under enough load can perform worse than just taking a lock up front would have. That's the signal to switch that specific hot path to pessimistic locking (or a queue) rather than optimistic retries.

Question 40

Walk through the OAuth2 authorization code flow — what actually happens when a user clicks "Sign in with Google"?

Accepted Answer

Your app redirects the user's browser to Google's authorization endpoint with your `client_id`, a `redirect_uri`, and the scopes you're requesting. The user logs into Google (if not already) and approves the requested access. Google redirects the browser back to your `redirect_uri` with a short-lived, single-use authorization `code` in the URL.

Your backend then takes that code and makes a *server-to-server* call to Google's token endpoint, passing the code plus your `client_secret`, and gets back an access token (and usually a refresh token) in exchange. The critical design point is that the actual token exchange happens server-to-server with a secret the browser never sees — the code that briefly appears in the browser's URL is useless on its own to an attacker who intercepts it, since exchanging it also requires the client secret only your backend holds.

Question 41

Why should access tokens be short-lived, and what does refresh token rotation add on top of that?

Accepted Answer

A short-lived access token (minutes, not days) limits the blast radius if it leaks — an attacker who steals it from a compromised device or an exposed log only has a small window before it expires on its own, versus a token valid for weeks giving them long-term access. The tradeoff is the user would need to re-login constantly, which is where the refresh token comes in: it's longer-lived, stored more carefully (often an httpOnly cookie), and used only to silently mint new access tokens without bothering the user.

Refresh token rotation adds one more layer: every time a refresh token is used, the server issues a brand new refresh token and invalidates the old one. This means if an attacker steals a refresh token and uses it, and the legitimate user's client later tries to use the (now-invalidated) old one, the server can detect that reuse and revoke the whole token family — catching theft that a static, never-rotated refresh token would let slide undetected indefinitely.

Question 42

What are the common strategies for versioning a public API, and what are the tradeoffs?

Accepted Answer

URL versioning (`/api/v2/users`) is the most visible and simplest to reason about — clients explicitly opt into a version, and you can run v1 and v2 side by side on the same server. Header versioning (`Accept: application/vnd.myapi.v2+json`) keeps URLs clean but is less discoverable and harder to test by just pasting a URL in a browser. Some APIs avoid versioning altogether by only ever making additive, backward-compatible changes (new optional fields, never removing or repurposing existing ones) — GraphQL leans heavily on this approach.

Whichever you pick, the real cost is maintaining multiple versions in production simultaneously — you need a real deprecation policy (a sunset date communicated well in advance) or you end up supporting v1 forever because some client never migrated off it.

Question 43

Cursor-based vs offset-based pagination — why do high-traffic APIs prefer cursors?

Accepted Answer

Offset pagination (`LIMIT 20 OFFSET 100`) is simple but has two real problems at scale: the database still has to scan and discard the first 100 rows before returning the next 20, getting slower the deeper you page; and if a row is inserted or deleted while a user is paging, the offset shifts under them, causing skipped or duplicated items between pages.

Cursor pagination instead uses a stable, unique value from the last item you saw (usually an id or a created-at timestamp+id combo) as the starting point for the next page: `WHERE id > :lastSeenId ORDER BY id LIMIT 20`. This is a direct indexed lookup regardless of how deep you page, and it's immune to the insert/delete shifting problem since it's anchored to an actual row, not a numeric position. The tradeoff is you lose the ability to jump directly to "page 7" — cursors only support moving forward/backward from where you are, which is fine for infinite-scroll feeds but awkward for a numbered-page UI.

Question 44

What do the ETag and Cache-Control headers actually do, and how do they work together?

Accepted Answer

`Cache-Control` tells the browser (and any CDN/proxy in between) how long a response can be reused without asking the server at all — `Cache-Control: max-age=3600` means "don't even ask me again for an hour, just reuse what you have." `ETag` handles what happens *after* that freshness window expires: the server tags a response with a hash/version identifier, and once the cached copy goes stale, the browser sends that ETag back in an `If-None-Match` header; if the resource hasn't actually changed, the server replies `304 Not Modified` with no body at all, saving the bandwidth of re-sending unchanged content while still confirming freshness.

Example: a JS bundle with a hash in its filename (`app.3f9a1c.js`) can use `Cache-Control: max-age=31536000, immutable` since the filename itself changes whenever the content does — no ETag round trip ever needed. An API response for data that changes occasionally is a better fit for a short `max-age` plus an ETag, so clients avoid re-downloading identical data on every refresh.

Question 45

What is cache stampede (thundering herd), and how do you prevent it?

Accepted Answer

It happens when a popular cache key expires and a large number of concurrent requests all miss the cache at essentially the same instant — every one of them then hits the database (or an expensive computation) simultaneously to regenerate the same value, which can spike load enough to take the database down, ironically because of the cache that was supposed to protect it.

A few standard mitigations: add jitter to TTLs so keys for similar items don't all expire at the exact same second; use a short-lived lock so only the first request that misses actually recomputes the value while the rest either wait briefly or get served the (slightly) stale value in the meantime; or proactively refresh hot keys in the background before they expire, so a real cache miss on a popular key essentially never happens.

```js
async function getWithStampedeGuard(key, computeFn, ttl) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);
  const gotLock = await redis.set(`lock:${key}`, '1', 'NX', 'EX', 10); // only one caller wins the lock
  if (!gotLock) { await sleep(50); return getWithStampedeGuard(key, computeFn, ttl); } // others wait and retry
  const value = await computeFn();
  await redis.set(key, JSON.stringify(value), 'EX', ttl);
  return value;
}
```

Question 46

What is the saga pattern, and why do you need it for a transaction that spans multiple microservices?

Accepted Answer

A single database transaction can atomically roll back if any step fails, but that guarantee doesn't cross a network boundary — you can't wrap a call to the Orders service and a call to the Payments service in one ACID transaction. A saga instead breaks a multi-service operation into a sequence of local transactions, each with a defined *compensating action* that undoes it if a later step in the sequence fails.

Example: placing an order might be (1) reserve inventory, (2) charge payment, (3) schedule shipping. If step 2 fails, the saga doesn't roll back a transaction — it explicitly calls the compensating action for step 1 (release the inventory reservation) to bring the system back to a consistent state. This can be orchestrated centrally (a saga coordinator explicitly calls each step and its compensation on failure) or choreographed (each service reacts to events from the previous one and emits its own) — orchestration is easier to reason about and debug; choreography avoids a central point of coupling but makes the overall flow harder to see in one place.

Question 47

What is the transactional outbox pattern, and what specific problem does it solve?

Accepted Answer

It solves the "dual write" problem: if a service needs to both update its own database *and* publish an event to a message queue for the same logical action (e.g. save an order, then publish "order created"), doing these as two separate operations is unsafe — the DB write can succeed and the queue publish can fail (or vice versa), leaving the system in an inconsistent state with no automatic way to detect it.

The outbox pattern solves this by writing the event into an "outbox" table in the *same* database transaction as the business data change — so both either commit together or neither does, which a single database transaction can guarantee. A separate background process (or a change-data-capture tool like Debezium reading the DB's write-ahead log) then reads unpublished rows from the outbox table and actually publishes them to the message queue, marking them sent once confirmed.

```sql
BEGIN;
INSERT INTO orders (id, user_id, total) VALUES (...);
INSERT INTO outbox (event_type, payload, published) VALUES ('order.created', '{...}', false);
COMMIT; -- both succeed or both roll back together
```

This guarantees the event is eventually published if and only if the order was actually saved — no lost events, no phantom events for a save that never happened.

Question 48

What is CQRS, and when is it actually worth the added complexity?

Accepted Answer

CQRS (Command Query Responsibility Segregation) means splitting your write model (commands that change state) from your read model (queries that fetch state), rather than using one unified model/schema for both. This lets you shape the read side purely for how it's queried — a denormalized, pre-joined, maybe even differently-stored (e.g. Elasticsearch for search, a normalized SQL schema for writes) view optimized for reads — without that read-optimized shape constraining or complicating how writes are validated and persisted.

It's genuinely worth it when read and write patterns are very different in shape or scale — e.g. a product catalog written rarely by admins but queried millions of times a day with complex filtering, where a denormalized, cache-friendly read model pays for itself. It's usually overkill for a standard CRUD app where reads and writes touch the same shape of data anyway — there you're just adding synchronization complexity (keeping the read model eventually consistent with the write model) for no real benefit, which is the classic ponytail-style over-engineering trap with this pattern.

Question 49

How does an idempotency key work for a payment API, and why isn't the webhook-signature dedupe from earlier the same mechanism?

Accepted Answer

An idempotency key protects the *client-initiated* request path — the client generates a unique key (e.g. a UUID) per logical operation ("charge this cart once") and sends it in a header on the POST. The server checks whether it's already processed that key: if yes, it returns the same stored response without re-running the charge; if no, it processes the request and stores the key-to-response mapping (in a table with a unique constraint on the key). This protects against the client's own retries — a mobile app that times out waiting for a response and retries the exact same tap doesn't double-charge the customer.

This is a different mechanism from webhook dedup (as in the earlier webhook question) because the direction is reversed: a webhook dedupe protects the *server* from a third party's retries of an inbound notification using *their* event id, while an idempotency key protects a downstream service from *your own client's* retries of an outbound request, using a key *you* generate. Both use the same underlying trick — a unique constraint on an id that gates whether processing happens — but on opposite sides of the request.

```js
app.post('/charges', async (req, res) => {
  const key = req.headers['idempotency-key'];
  const existing = await db.idempotencyKeys.findOne({ key });
  if (existing) return res.status(existing.statusCode).json(existing.response);
  const result = await processCharge(req.body);
  await db.idempotencyKeys.create({ key, statusCode: 200, response: result });
  res.json(result);
});
```

Question 50

What's the difference between at-least-once and exactly-once delivery in a distributed messaging system, and how do you get exactly-once behavior in practice?

Accepted Answer

At-least-once delivery guarantees a message will be delivered, but possibly more than once — if a consumer processes a message and crashes before acknowledging it, the broker (SQS, Kafka, RabbitMQ) will redeliver it to be safe, so your consumer might see the same message twice. Exactly-once delivery — a message delivered and processed precisely one time, no duplicates, no drops — is genuinely very hard to guarantee end-to-end across a real network, because you can never fully distinguish "the consumer crashed before processing" from "the consumer crashed after processing but before acknowledging."

What's actually achievable and what most systems do instead is at-least-once delivery plus an idempotent consumer: the broker may redeliver, but the consumer's processing logic makes handling the same message twice produce the same end result as handling it once (checking a processed-message-id table before acting, same pattern as the webhook dedup and idempotency-key answers above). In effect, you get "exactly-once processing" as an application-level property built on top of an at-least-once delivery guarantee, rather than trying to get the messaging infrastructure itself to promise exactly-once.

Question 51

What is the difference between the GET and POST HTTP methods?

Accepted Answer

GET is used to fetch/read data from a server. Any parameters go in the URL itself (as a query string), the request has no body, and browsers/proxies are free to cache a GET response and even prefetch it — which is exactly why GET should never be used to change data on the server (like deleting a record), since something could trigger that request without the user meaning to.

POST is used to send data to the server, usually to create something or trigger an action with side effects (submitting a form, logging in, creating a new user). The data goes in the request body instead of the URL, so it can carry much larger and more complex payloads, and it isn't cached by default.

A simple way to remember it: GET is like asking a librarian "can I see book #42" — you're just looking, nothing changes. POST is like handing the librarian a new book to add to the shelf — you're submitting something that changes what's there.

```js
// GET: read a user, no body, data in the URL
fetch('/api/users/42');

// POST: create a user, data in the body
fetch('/api/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'Riya', email: 'riya@example.com' }),
});
```

Question 52

What's the difference between cookies, localStorage, and sessionStorage for storing data in the browser?

Accepted Answer

All three let a website store small bits of data in the user's browser, but they differ in how long the data lasts and who can see it. A cookie is the oldest of the three: it's automatically attached to every HTTP request sent to that domain, which makes it useful for things like session/auth tokens the server needs on every request, but also means it adds overhead to every request and has a small size limit (about 4KB). Cookies can have an expiry date you set, or vanish when the browser closes if you don't set one.

localStorage and sessionStorage are both accessed only via JavaScript (`window.localStorage` / `window.sessionStorage`) and are never sent to the server automatically — the server only sees that data if your code explicitly sends it in a request. The difference between the two is lifetime: localStorage persists indefinitely (it survives closing the tab, closing the browser, even restarting the computer) until code or the user clears it, while sessionStorage is wiped as soon as that specific browser tab is closed.

A practical example: remembering a user's chosen theme ("dark mode") fits localStorage, since you want it to persist across visits. Keeping track of which step of a multi-step form the user is on fits sessionStorage, since it's fine for that to reset if they close the tab. An auth session token that the server needs to validate on every API call is the classic cookie use case.

```js
localStorage.setItem('theme', 'dark');       // persists across browser restarts
sessionStorage.setItem('formStep', '2');     // cleared when the tab closes
document.cookie = 'sessionId=abc123; max-age=3600'; // sent automatically with every request to this domain
```

Fullstack Interview Questions & Answers

Ready to practice these live?