Q: Implement request de-duplication using an idempotency key with a TTL.

An idempotency key lets a client safely retry a mutating request (like "charge this card" or "create this order") without it executing twice, by having the client generate a unique key per logical operation and send it in a header. The server stores the key along with the response it produced, and if the same key arrives again, it returns the cached response instead of re-running the operation. The TTL exists because idempotency keys shouldn't live forever — a client only needs the safety net for the retry window (typically minutes to a day); after that, the same key can be safely garbage collected or even reused for a different operation without risk. ```javascript async function handlePayment(req, res) { const key = req.headers['idempotency-key']; const existing = await redis.get(`idem:${key}`); if (existing) return res.json(JSON.parse(existing)); const result = await chargeCard(req.body); await redis.set(`idem:${key}`, JSON.stringify(result), 'EX', 86400); // 24h TTL return res.json(result); } ``` The subtle part is handling concurrent duplicate requests that arrive before the first one has finished (e.g., a client double-clicking "pay"). A naive check-then-set has a race window, so production implementations set a placeholder ("in progress") atomically first (e.g., Redis `SET key value NX`), and have the second concurrent request either wait/poll or return a 409 until the first completes.

Q: Given a list of orders, produce per-customer totals with the top item per customer.

This is a classic "group by" problem: for each customer, sum up their order totals, and separately find which single item they bought the most of. You iterate once building a map of customerId -> { total, itemCounts }, then a lightweight second pass picks the max item per customer from that map. ```javascript function summarize(orders) { const byCustomer = {}; for (const o of orders) { const c = byCustomer[o.customerId] ??= { total: 0, items: {} }; c.total += o.amount; c.items[o.itemName] = (c.items[o.itemName] || 0) + o.quantity; } for (const c of Object.values(byCustomer)) { c.topItem = Object.entries(c.items).sort((a, b) => b[1] - a[1])[0][0]; } return byCustomer; } ``` This runs in O(n) for the aggregation and O(k log k) per customer for picking the top item, where k is the number of distinct items — fine for realistic order volumes. The same shape shows up constantly in backend work: sales dashboards, "most-purchased product" reports, or per-user activity summaries, and it's the reason `GROUP BY` plus a window function (`ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY qty DESC)`) exists in SQL — it's this exact pattern pushed into the database instead of application code.

Q: Implement an LRU cache with get/put in O(1).

An LRU (Least Recently Used) cache evicts the item that hasn't been accessed in the longest time once it's full. To get O(1) get and put, you combine a hash map (for O(1) lookup by key) with a doubly linked list (for O(1) reordering of recency) — the hash map stores key -> node, and the linked list keeps nodes ordered from most-recently-used (head) to least-recently-used (tail). On every get or put, you move that node to the head; when the cache is over capacity, you evict the tail. ```javascript class LRUCache { constructor(capacity) { this.capacity = capacity; this.map = new Map(); // Map preserves insertion order in JS } get(key) { if (!this.map.has(key)) return -1; const value = this.map.get(key); this.map.delete(key); this.map.set(key, value); // re-insert = moves to "most recent" end return value; } put(key, value) { if (this.map.has(key)) this.map.delete(key); else if (this.map.size >= this.capacity) { this.map.delete(this.map.keys().next().value); // evict least-recent (first) } this.map.set(key, value); } } ``` JavaScript's `Map` happens to preserve insertion order and supports O(1) delete/re-insert, so it can stand in for the hash-map-plus-linked-list combo without writing the linked list by hand. In languages without that guarantee (like a plain hash map in Java or C), you build the doubly linked list explicitly, with each node holding prev/next pointers, because array-based lists would need O(n) to move an element to the front. This exact structure backs real production caches — Redis's `maxmemory-policy allkeys-lru`, browser HTTP caches, and CPU cache eviction all use the LRU-approximation idea, though at extreme scale many systems use approximate LRU (Redis samples a few keys rather than maintaining a perfect list) because a perfect global order is expensive to maintain under high concurrency.

Question 1

Implement a sliding-window rate limiter: allow N requests per user per minute.

Accepted Answer

A sliding-window rate limiter tracks the exact timestamps of a user's recent requests and only counts the ones that fall inside the last N seconds/minute, instead of resetting a counter at fixed clock boundaries. That fixed-window approach (e.g., "reset count at the top of every minute") lets a user send N requests in the last second of one window and another N in the first second of the next, effectively 2N requests in two seconds — the sliding window closes that gap.

A simple implementation keeps a per-user list (or sorted set) of request timestamps. On each request, drop timestamps older than (now - windowSize), then check if the remaining count is below the limit; if so, record the new timestamp and allow, otherwise reject.

```javascript
function isAllowed(userId, limit = 100, windowMs = 60_000) {
  const now = Date.now();
  const timestamps = store.get(userId) || [];
  const recent = timestamps.filter(t => now - t < windowMs);
  if (recent.length >= limit) {
    store.set(userId, recent);
    return false;
  }
  recent.push(now);
  store.set(userId, recent);
  return true;
}
```

In production this is usually backed by Redis using a sorted set (ZADD with score = timestamp, ZREMRANGEBYSCORE to evict old entries, ZCARD to count) so it works across multiple app servers, or approximated with a "sliding window counter" that blends the previous and current fixed-window counts by weight — cheaper than storing every timestamp, at the cost of slight inaccuracy.

Question 2

Design cursor-based pagination logic over a sorted dataset, handling inserts between pages.

Accepted Answer

Cursor-based pagination returns items after a specific position (the "cursor") rather than by numeric offset. The cursor is typically an opaque, encoded value derived from the last row returned — usually its sort key plus a tiebreaker like id — and the next page's query is "give me rows where (sort_key, id) is past the cursor, ordered the same way, limited to N."

The reason this matters is offset pagination (LIMIT 20 OFFSET 40) breaks when rows are inserted or deleted between page loads: the database still counts from the start, so a new row shifted into position 41 causes duplicates or skipped rows on the next page. A cursor anchors to actual data, not a position count, so it doesn't drift when the underlying set changes.

```sql
-- page 1
SELECT id, created_at FROM orders ORDER BY created_at DESC, id DESC LIMIT 20;
-- next page uses the last row's (created_at, id) as the cursor
SELECT id, created_at FROM orders
WHERE (created_at, id) < ('2026-08-01 10:00:00', 943)
ORDER BY created_at DESC, id DESC LIMIT 20;
```

The tiebreaker column (id) makes it safe against ties on the primary sort column — two orders with an identical timestamp would otherwise be ambiguous about which page they belong to. In practice you base64-encode the (sort_key, id) pair into a single opaque string so clients just pass it back without knowing its internal shape, which also lets you change the encoding later without breaking API compatibility.

Question 3

Implement request de-duplication using an idempotency key with a TTL.

Accepted Answer

An idempotency key lets a client safely retry a mutating request (like "charge this card" or "create this order") without it executing twice, by having the client generate a unique key per logical operation and send it in a header. The server stores the key along with the response it produced, and if the same key arrives again, it returns the cached response instead of re-running the operation.

The TTL exists because idempotency keys shouldn't live forever — a client only needs the safety net for the retry window (typically minutes to a day); after that, the same key can be safely garbage collected or even reused for a different operation without risk.

```javascript
async function handlePayment(req, res) {
  const key = req.headers['idempotency-key'];
  const existing = await redis.get(`idem:${key}`);
  if (existing) return res.json(JSON.parse(existing));

const result = await chargeCard(req.body);
  await redis.set(`idem:${key}`, JSON.stringify(result), 'EX', 86400); // 24h TTL
  return res.json(result);
}
```

The subtle part is handling concurrent duplicate requests that arrive before the first one has finished (e.g., a client double-clicking "pay"). A naive check-then-set has a race window, so production implementations set a placeholder ("in progress") atomically first (e.g., Redis `SET key value NX`), and have the second concurrent request either wait/poll or return a 409 until the first completes.

Question 4

Given a list of orders, produce per-customer totals with the top item per customer.

Accepted Answer

This is a classic "group by" problem: for each customer, sum up their order totals, and separately find which single item they bought the most of. You iterate once building a map of customerId -> { total, itemCounts }, then a lightweight second pass picks the max item per customer from that map.

```javascript
function summarize(orders) {
  const byCustomer = {};
  for (const o of orders) {
    const c = byCustomer[o.customerId] ??= { total: 0, items: {} };
    c.total += o.amount;
    c.items[o.itemName] = (c.items[o.itemName] || 0) + o.quantity;
  }
  for (const c of Object.values(byCustomer)) {
    c.topItem = Object.entries(c.items).sort((a, b) => b[1] - a[1])[0][0];
  }
  return byCustomer;
}
```

This runs in O(n) for the aggregation and O(k log k) per customer for picking the top item, where k is the number of distinct items — fine for realistic order volumes. The same shape shows up constantly in backend work: sales dashboards, "most-purchased product" reports, or per-user activity summaries, and it's the reason `GROUP BY` plus a window function (`ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY qty DESC)`) exists in SQL — it's this exact pattern pushed into the database instead of application code.

Question 5

Parse web-server log lines and report the 5 most frequent endpoints with average latency.

Accepted Answer

This asks you to parse unstructured (or semi-structured) log lines, extract the endpoint and latency from each, and produce the top 5 endpoints by request count along with their average latency. The main work is: a robust parser/regex for the log format, an aggregation map keyed by endpoint accumulating count and total latency, and a sort-and-slice for the top 5.

```javascript
// example line: 2026-08-24T10:00:01Z GET /api/orders 200 142ms
const LOG_RE = /^(\S+) (\S+) (\S+) (\d+) (\d+)ms$/;

Real-world variants of this problem show up in every observability pipeline — nginx/Apache access-log analysis, building a poor-man's APM before Datadog is wired up, or a take-home task simulating exactly this. The gotchas interviewers look for: malformed lines shouldn't crash the parser (skip and continue), very large log files should be streamed line-by-line rather than loaded fully into memory, and "average" should be computed from a running sum/count rather than storing every latency value.

Question 6

Make a shared counter safe under concurrent increments; explain the failure mode without it.

Accepted Answer

A plain `counter++` is not atomic — it's actually three steps: read the current value, add one, write it back. Under concurrency, two threads can both read the same value, both increment it in isolation, and both write back the same result, silently losing one increment. This is the classic "lost update" race condition, and it gets worse under load: the more concurrent writers, the more increments quietly vanish.

The fix depends on the language/runtime. In a genuinely multi-threaded environment (Java, Go, C++), you use an atomic primitive or a mutex around the read-modify-write:

```java
AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet(); // atomic, no lock needed
```

```go
var mu sync.Mutex
var counter int
func increment() {
    mu.Lock()
    counter++
    mu.Unlock()
}
```

In Node.js, a single JS thread means you rarely get a torn read-modify-write within one process, but you get the equivalent problem across multiple server instances sharing state — which is why a shared counter (page views, rate-limit counts, inventory) usually lives in Redis and uses `INCR`, which is atomic at the Redis server level regardless of how many app servers call it concurrently. The general principle: any shared mutable state accessed by more than one execution context needs either a lock, an atomic instruction, or to be pushed into something (a database, Redis) that guarantees atomicity for you.

Question 7

Process a queue of jobs with at most K running concurrently.

Accepted Answer

A worker pool processes a queue of jobs with a fixed number of concurrent workers (K), so you get parallelism without spawning unbounded threads/tasks that could exhaust memory or overwhelm a downstream dependency (like a database or third-party API). The pattern is: a shared queue, and exactly K workers that each loop "pull a job, process it, repeat" until the queue is empty.

```javascript
async function runWithConcurrency(jobs, k, handler) {
  const queue = [...jobs];
  const results = [];

async function worker() {
    while (queue.length) {
      const job = queue.shift();
      results.push(await handler(job));
    }
  }

await Promise.all(Array.from({ length: k }, worker));
  return results;
}
```

In Go this maps naturally onto goroutines and a channel acting as the queue: K goroutines range over a jobs channel, and a separate goroutine feeds it, closing it when done so the workers exit their range loop naturally.

```go
jobs := make(chan Job, 100)
var wg sync.WaitGroup
for i := 0; i < k; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        for job := range jobs {
            process(job)
        }
    }()
}
```

The interesting edge cases interviewers probe: what happens if one job throws/panics (shouldn't kill the whole pool — catch per-job and record the failure), how do you know when all work is done (WaitGroup / Promise.all), and how do you handle backpressure if jobs are still being produced while workers consume (a bounded channel/queue forces the producer to block rather than growing memory unboundedly).

Question 8

Implement an LRU cache with get/put in O(1).

Accepted Answer

An LRU (Least Recently Used) cache evicts the item that hasn't been accessed in the longest time once it's full. To get O(1) get and put, you combine a hash map (for O(1) lookup by key) with a doubly linked list (for O(1) reordering of recency) — the hash map stores key -> node, and the linked list keeps nodes ordered from most-recently-used (head) to least-recently-used (tail). On every get or put, you move that node to the head; when the cache is over capacity, you evict the tail.

```javascript
class LRUCache {
  constructor(capacity) {
    this.capacity = capacity;
    this.map = new Map(); // Map preserves insertion order in JS
  }
  get(key) {
    if (!this.map.has(key)) return -1;
    const value = this.map.get(key);
    this.map.delete(key);
    this.map.set(key, value); // re-insert = moves to "most recent" end
    return value;
  }
  put(key, value) {
    if (this.map.has(key)) this.map.delete(key);
    else if (this.map.size >= this.capacity) {
      this.map.delete(this.map.keys().next().value); // evict least-recent (first)
    }
    this.map.set(key, value);
  }
}
```

JavaScript's `Map` happens to preserve insertion order and supports O(1) delete/re-insert, so it can stand in for the hash-map-plus-linked-list combo without writing the linked list by hand. In languages without that guarantee (like a plain hash map in Java or C), you build the doubly linked list explicitly, with each node holding prev/next pointers, because array-based lists would need O(n) to move an element to the front. This exact structure backs real production caches — Redis's `maxmemory-policy allkeys-lru`, browser HTTP caches, and CPU cache eviction all use the LRU-approximation idea, though at extreme scale many systems use approximate LRU (Redis samples a few keys rather than maintaining a perfect list) because a perfect global order is expensive to maintain under high concurrency.

Question 9

What is the difference between REST and GraphQL?

Accepted Answer

REST exposes multiple fixed endpoints, each returning a fixed shape of data determined by the server (e.g., GET /users/5 returns the whole user object, GET /users/5/orders returns orders). GraphQL exposes a single endpoint where the client sends a query describing exactly which fields it wants, across potentially multiple related resources, and the server returns exactly that shape — nothing more, nothing less.

The practical trade-off: REST is simpler to cache (HTTP caching works naturally per-URL), simpler to reason about, and battle-tested with existing tooling. GraphQL avoids over-fetching (getting a huge user object when you only needed the name) and under-fetching (needing 3 round trips to assemble a mobile screen), at the cost of needing a resolver layer, more complex caching, and a real risk of a client crafting an expensive nested query that overloads your backend (which is why production GraphQL servers add query depth/complexity limits).

Example: a mobile screen needing a user's name, their last 3 orders, and each order's item count. In REST that's typically 2-3 requests. In GraphQL it's one query:
```graphql
{
  user(id: 5) {
    name
    orders(limit: 3) { id itemCount }
  }
}
```

Question 10

Explain the ACID properties in database transactions.

Accepted Answer

ACID is the set of guarantees a database transaction makes so that concurrent, potentially-failing operations don't corrupt data. Atomicity means a transaction either fully commits or fully rolls back — no partial writes. Consistency means a transaction moves the database from one valid state to another, respecting all constraints (foreign keys, unique constraints, check constraints). Isolation means concurrent transactions don't see each other's uncommitted intermediate state (governed by isolation levels). Durability means once a transaction commits, it survives a crash — typically via a write-ahead log flushed to disk before acknowledging the commit.

A concrete example: transferring $100 from account A to account B needs two writes (debit A, credit B) wrapped in one transaction. If the process crashes after debiting A but before crediting B, atomicity guarantees the whole transaction rolls back rather than leaving $100 vanished. Without ACID guarantees, that partial failure would silently lose money — which is exactly why financial systems, and most backend systems handling anything stateful, lean on a relational database's transaction support rather than reimplementing this logic in application code.

Question 11

What is database indexing and how does a B-tree index speed up queries?

Accepted Answer

An index is a separate, ordered data structure the database maintains alongside a table so it can find rows matching a condition without scanning every row. Most relational databases default to a B-tree index: a balanced tree where each node holds sorted keys and pointers to either child nodes or the actual row data, so a lookup, range scan, or sorted traversal all run in O(log n) instead of O(n).

Concretely, `SELECT * FROM users WHERE email = 'x@y.com'` without an index on `email` forces a full table scan — checking every row. With `CREATE INDEX idx_users_email ON users(email)`, the database walks the B-tree in a handful of comparisons to jump straight to the matching row(s). The trade-off is that every index speeds up reads on that column but slows down writes (every INSERT/UPDATE/DELETE has to update the index too) and takes extra storage — which is why you index columns you actually filter/sort/join on, not every column defensively.

Question 12

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

Accepted Answer

The N+1 query problem happens when code fetches a list of N parent records with one query, then loops over them and issues a separate query per record to fetch related data — resulting in 1 + N total queries instead of 2. It's extremely common with ORMs where lazy-loading a relationship inside a loop looks innocent in the code but silently fires a query per iteration.

```javascript
// N+1: one query for orders, then one query per order for its customer
const orders = await Order.findAll(); // 1 query
for (const order of orders) {
  order.customer = await Customer.findByPk(order.customerId); // N queries
}
```

The fix is to fetch the related data in bulk upfront — either an explicit JOIN, or the ORM's eager-loading feature, which issues one extra query with a `WHERE customer_id IN (...)` instead of N separate ones:
```javascript
const orders = await Order.findAll({ include: Customer }); // 1-2 queries total
```
This matters a lot in practice — an endpoint that works fine in dev with 5 rows can silently do 500 database round trips in production with 500 rows, and it's one of the most common real-world performance bugs found in code review.

Question 13

Explain the CAP theorem.

Accepted Answer

CAP theorem says a distributed data system can only guarantee two of three properties at the same time when a network partition occurs: Consistency (every read sees the latest write), Availability (every request gets a response, even if it's not the latest data), and Partition tolerance (the system keeps working despite network failures between nodes). Since real networks do partition, partition tolerance is basically non-negotiable for a distributed system, so in practice the real choice is between consistency and availability during a partition.

A CP system (like Zookeeper, or a single-leader database configured for synchronous replication) will refuse to serve a request rather than risk returning stale data if it can't confirm with enough nodes. An AP system (like Cassandra or DynamoDB in default configuration) will keep answering requests during a partition, possibly returning slightly stale data, and reconcile once the partition heals. Concretely: during a network split between two data centers, a CP shopping-cart service might reject writes rather than risk two conflicting carts, while an AP system would accept writes in both data centers and merge them later — the right choice depends entirely on whether staleness or unavailability is more costly for that specific feature.

Question 14

What's the difference between horizontal and vertical scaling?

Accepted Answer

Vertical scaling means making a single machine more powerful — more CPU, RAM, faster disk — to handle more load. Horizontal scaling means adding more machines and distributing load across them (via a load balancer, sharding, or partitioning). Vertical scaling is simpler (no code changes, no distributed-systems complexity) but hits a hard ceiling and is a single point of failure. Horizontal scaling has effectively no ceiling and gives you redundancy, but requires your application to be stateless (or explicitly handle state, like sticky sessions or a shared session store) since requests can land on any instance.

A concrete example: a Postgres database under heavy read load can be vertically scaled by moving to a bigger instance type, which buys time cheaply, but eventually the team adds read replicas (horizontal scaling for reads) or shards the data (horizontal scaling for writes) because no single machine can keep up with the load ceiling forever.

Question 15

What is a message queue and when would you use Kafka vs RabbitMQ?

Accepted Answer

Both are message brokers, but they're built for different shapes of problem. RabbitMQ is a traditional message queue: a producer publishes a message, it sits in a queue, a consumer takes it off and acknowledges it, and then it's gone — ideal for task distribution (job queues, background work) where each message should be processed exactly once by exactly one consumer. Kafka is a distributed append-only log: messages are written to partitioned, ordered logs and retained for a configurable period regardless of whether anyone has read them yet, and multiple independent consumer groups can each read the same stream at their own pace — ideal for event streaming where many downstream systems need the same events.

Concretely: "send this email" is a RabbitMQ-shaped problem — one task, one worker, done. "Every order placed on the platform" is a Kafka-shaped problem — the fraud team, the analytics team, and the recommendations team may all want to independently replay or consume that same stream of events, potentially re-reading history, which Kafka's retained log supports and RabbitMQ's consume-and-delete model doesn't naturally fit.

Question 16

Explain the difference between JWT and session-based authentication.

Accepted Answer

Session-based auth stores session state on the server (in memory, Redis, or a database) keyed by a session ID, and the client just holds an opaque cookie referencing that ID. The server looks up the session on every request to check who's logged in and what they're allowed to do. JWT (JSON Web Token) auth instead encodes the user's identity and claims directly into a signed token that the client holds and sends with every request — the server verifies the signature without needing to look anything up, making it stateless.

The trade-off: sessions are easy to revoke instantly (just delete the server-side session) but require a shared session store to work across multiple server instances. JWTs scale better because any server can verify them without a shared store, but revoking a single JWT before it expires is hard — the server has already handed out a self-contained token it can't "unsign," so you typically use short expiries plus a refresh-token flow, or maintain a denylist (which reintroduces the statefulness JWTs were meant to avoid).

Question 17

What is CORS and why does the browser enforce it?

Accepted Answer

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that blocks a webpage on one origin (say `app.example.com`) from making requests to a different origin (`api.otherapp.com`) unless that server explicitly opts in via response headers. Without CORS, a malicious site could silently make authenticated requests to your bank's API using your logged-in browser session and read the response — the browser enforces CORS specifically to prevent that.

When a request is "non-simple" (custom headers, methods like PUT/DELETE, JSON content-type in some cases), the browser first sends a preflight `OPTIONS` request asking "are you okay with this?", and the server responds with headers like `Access-Control-Allow-Origin: https://app.example.com` to grant permission. It's worth noting CORS is purely a browser-enforced rule — it does nothing to stop a server-to-server request or a curl call, because those clients don't implement the same-origin policy; it protects browser users specifically, not your API in general.

Question 18

Explain the token bucket algorithm for rate limiting and how it differs from sliding window.

Accepted Answer

The token bucket algorithm models rate limiting as a bucket that holds up to a fixed number of tokens, refilled at a steady rate (e.g., 10 tokens/second up to a max of 100). Every request consumes one token; if the bucket's empty, the request is rejected or delayed. This naturally allows short bursts (if the bucket's been filling while idle, you can burst up to its capacity) while still enforcing a long-run average rate — which is why it's the standard choice for API gateways that want to tolerate occasional spikes.

Sliding window instead counts actual requests within a trailing time window and rejects once the count hits the limit — it enforces a hard cap with no burst allowance beyond the window itself, and is simpler to reason about ("no more than N in any 60-second period") but doesn't smooth traffic the way a token bucket's steady refill does. In practice: a public API that wants predictable, bursty client behavior handled gracefully uses token bucket; a system that wants a strict, simple guarantee uses sliding window.

Question 19

What is a circuit breaker pattern and when should you use one?

Accepted Answer

A circuit breaker wraps calls to a dependency (a downstream service, a database, a third-party API) and stops sending requests to it once it detects that dependency is failing, instead of letting every caller keep retrying against something that's clearly down. It has three states: closed (normal, requests pass through), open (dependency is failing, requests fail immediately without even trying), and half-open (after a cooldown, it lets a few test requests through to see if the dependency has recovered, then closes or reopens based on the result).

The point is preventing cascading failure: if a payment provider starts timing out, and every request to your checkout service blocks waiting on it, your checkout service's own threads/connections get exhausted waiting, and it goes down too — even though the actual problem was one external dependency. A circuit breaker (e.g., resilience4j in Java, or `opossum` in Node) trips after a failure threshold and fails fast instead, keeping your own service responsive while the dependency recovers.

Question 20

Explain exponential backoff with jitter for retries.

Accepted Answer

When a request to a flaky or overloaded dependency fails, retrying immediately often makes things worse — especially if many clients failed at the same time and all retry simultaneously, creating a new burst of load right as the dependency was trying to recover. Exponential backoff spaces out retries by doubling the delay each time (1s, 2s, 4s, 8s...) so a persistently failing dependency gets progressively less pressure and more room to recover.

Jitter adds randomness to that delay so that many clients who failed at the same moment don't all retry at the exact same computed delay and cause a synchronized thundering herd against the recovering service.

```javascript
async function retryWithBackoff(fn, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try { return await fn(); }
    catch (err) {
      if (attempt === maxRetries - 1) throw err;
      const base = 2 ** attempt * 100;
      const jitter = Math.random() * base;
      await new Promise(r => setTimeout(r, base + jitter));
    }
  }
}
```
This is standard practice for calling any external API (AWS SDKs, Stripe's client libraries all implement this internally) and for retrying transient database connection failures.

Question 21

What is database sharding and what are common sharding strategies?

Accepted Answer

Sharding splits one logical dataset across multiple physical databases (shards) so no single machine has to hold or serve all the data — necessary once a dataset outgrows what vertical scaling or read replicas can handle for writes. The core decision is the shard key: the field used to decide which shard a given row lives on.

Range-based sharding puts contiguous key ranges on the same shard (e.g., users A-M on shard 1, N-Z on shard 2) — simple and good for range queries, but prone to hotspots if data isn't evenly distributed. Hash-based sharding applies a hash function to the shard key and distributes based on the hash, spreading load evenly but making range queries across shards expensive since sorted order is lost. Directory-based sharding keeps an explicit lookup table mapping keys to shards, which is the most flexible (you can rebalance by moving individual entries) but adds a lookup hop and a potential bottleneck at the directory itself.

A concrete example: sharding a multi-tenant SaaS database by `tenant_id` (hash-based) keeps each tenant's data together on one shard, while sharding a time-series events table by timestamp range lets you easily archive or drop old shards entirely.

Question 22

Explain read replicas and replication lag.

Accepted Answer

A read replica is a copy of a primary database that continuously applies the primary's writes (via streaming the write-ahead log or binlog) and serves read-only queries, letting you scale read throughput horizontally by pointing read traffic at replicas while writes still go to the primary. Replication lag is the delay between a write committing on the primary and that same write becoming visible on a replica — because replication happens asynchronously in most setups, there's always some window where a replica is behind.

This matters concretely in a "read-your-own-write" scenario: a user updates their profile, the write commits on the primary, the app immediately re-fetches the profile from a lagging replica, and the user sees their old data — looking like the update silently failed. The common fixes are routing that specific follow-up read to the primary, using a session-sticky strategy for a short window after a write, or in stricter cases using synchronous replication (at a latency cost) for data that can't tolerate any lag.

Question 23

What's the difference between optimistic and pessimistic locking?

Accepted Answer

Pessimistic locking assumes conflicts are likely, so it locks the row/resource before reading it for update, blocking any other transaction from touching it until the lock is released — e.g., `SELECT ... FOR UPDATE` in SQL. It guarantees no lost updates but hurts concurrency, since other transactions wanting the same row simply wait.

Optimistic locking assumes conflicts are rare: instead of locking, you read the data along with a version number, and when you write back, you check the version hasn't changed in the meantime (`UPDATE ... WHERE id = ? AND version = ?`); if zero rows were affected, someone else updated it first, and you retry. It scales much better under low-contention workloads since no locks are held during the "think time" between read and write, but under high contention it means more retries.

A concrete example: an e-commerce inventory decrement under flash-sale load is a strong candidate for pessimistic locking (contention is guaranteed), while a user editing their own profile is a good fit for optimistic locking (the same row is almost never edited concurrently, so paying a lock cost on every edit would be wasteful).

Question 24

What are database transaction isolation levels?

Accepted Answer

Isolation levels control how much one transaction can see of another transaction's in-progress changes, trading off consistency guarantees against concurrency/performance. Read Uncommitted allows dirty reads (seeing another transaction's uncommitted changes) — rarely used. Read Committed (Postgres's default) only ever sees committed data, but a value can change between two reads within the same transaction (non-repeatable read). Repeatable Read guarantees the same row read twice in one transaction returns the same value, but new rows matching a query can still appear (phantom read) in some databases. Serializable is the strictest — transactions behave as if run one at a time in some serial order, preventing all of the above anomalies, at the cost of more aborts/retries under contention.

A concrete example: under Read Committed, a report that reads `SUM(balance)` from an accounts table twice within the same transaction, with another transaction transferring money between two accounts in between, could see the total change even though a well-formed transfer shouldn't change the sum — a reporting job needing a single consistent snapshot would run under a stronger isolation level instead.

Question 25

What is a deadlock and how do databases detect and resolve them?

Accepted Answer

A deadlock happens when two (or more) transactions each hold a lock the other needs, so both wait forever — e.g., transaction A locks row 1 then wants row 2, while transaction B locks row 2 then wants row 1. Neither can proceed and neither will release its lock voluntarily.

Databases handle this by running a deadlock detector (often via a wait-for graph) that periodically checks for cycles among waiting transactions; when it finds one, it picks a "victim" transaction (usually the one that's done the least work) and forcibly aborts it with an error, releasing its locks so the other transaction can proceed. The application is expected to catch that deadlock error and retry the aborted transaction. The practical prevention strategy is to always acquire locks (or update rows) in a consistent order across your codebase — e.g., always lock the lower account ID first in a transfer — so the "each holds what the other wants" cycle can't form in the first place.

Question 26

Explain the outbox pattern for reliable event publishing.

Accepted Answer

The outbox pattern solves the problem of atomically updating your database and publishing an event about that update to a message broker — two systems that can't be wrapped in one transaction, which means a naive "write to DB, then publish to Kafka" can fail after the DB commit but before the publish succeeds, silently losing the event.

The fix: instead of publishing directly, you write the event into an "outbox" table in the same database transaction as your actual business write — so both succeed or fail together atomically, since they're now just two inserts in one transaction. A separate background process (or a change-data-capture tool like Debezium reading the database's write-ahead log) then reads unpublished rows from the outbox table and actually publishes them to the message broker.

```sql
BEGIN;
  UPDATE orders SET status = 'confirmed' WHERE id = 42;
  INSERT INTO outbox (event_type, payload) VALUES ('order_confirmed', '{"orderId":42}');
COMMIT;
```
This guarantees the event is emitted exactly when the business change actually committed, with no risk of the two getting out of sync.

Question 27

What is the saga pattern for distributed transactions?

Accepted Answer

A saga coordinates a business transaction that spans multiple services (and therefore multiple databases), where a traditional single ACID transaction isn't possible because no one database owns all the data. Instead, the saga breaks the operation into a sequence of local transactions, each in one service, and if a later step fails, it runs compensating transactions to undo the effects of the steps that already succeeded.

For example, booking a trip might involve: reserve a flight, reserve a hotel, charge the card. If the card charge fails after the flight and hotel are both reserved, a saga doesn't roll back a distributed transaction (there isn't one) — it explicitly calls "cancel hotel reservation" and "cancel flight reservation" to undo the prior steps. Sagas are typically implemented either as choreography (each service publishes an event and the next service reacts to it, no central coordinator) or orchestration (a central saga coordinator explicitly calls each step and decides when to compensate) — orchestration is easier to debug, choreography has less central coupling but makes the overall flow harder to see in one place.

Question 28

What is CQRS (Command Query Responsibility Segregation)?

Accepted Answer

CQRS separates the model used to write data (commands) from the model used to read it (queries), instead of using one model for both. Writes go through a model optimized for enforcing business rules and consistency, while reads are served from a separate, often denormalized, model optimized purely for the queries the UI actually needs — sometimes even backed by a different database technology entirely.

A concrete example: an order-processing system might write orders into a normalized relational schema, while a separate read model precomputes and stores a fully denormalized "order summary" document in something like Elasticsearch, updated asynchronously whenever an order changes, so the dashboard showing order history never has to run an expensive multi-table join. CQRS is genuinely useful when read and write patterns diverge a lot, but it adds real complexity (eventual consistency between the two models) — it's overkill for a CRUD app where one model serves both sides fine.

Question 29

Explain eventual consistency vs strong consistency.

Accepted Answer

Strong consistency means that once a write completes, every subsequent read (from any node) sees that write immediately — the system behaves as if there's a single copy of the data, even if it's physically replicated. Eventual consistency relaxes that: after a write, replicas will converge to the same value eventually, but for some window there's no guarantee a read returns the latest write.

The trade-off is almost always availability/latency versus correctness guarantees: enforcing strong consistency across geographically distributed replicas requires coordination that adds latency and can reduce availability during a partition, while eventual consistency lets each replica answer immediately from local data. A concrete example: DNS is eventually consistent — updating a record can take minutes to propagate everywhere, an accepted trade-off for DNS's massive read scale; by contrast, a bank balance check after a withdrawal generally needs strong consistency, because "eventually your balance will be correct" is not acceptable for financial correctness.

Question 30

What is a distributed lock and how would you implement one with Redis?

Accepted Answer

A distributed lock lets multiple independent processes/servers coordinate so only one of them performs a given critical section at a time — needed because a normal in-process mutex only protects threads within the same process, not another server entirely doing the same work concurrently. Redis is a common backing store because `SET key value NX PX ttl` is atomic: it sets the key only if it doesn't already exist, with an expiry, in one operation, so exactly one caller wins the lock.

```javascript
async function withLock(key, ttlMs, fn) {
  const token = crypto.randomUUID();
  const acquired = await redis.set(key, token, 'NX', 'PX', ttlMs);
  if (!acquired) throw new Error('lock held by another process');
  try {
    return await fn();
  } finally {
    const script = `if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end`;
    await redis.eval(script, 1, key, token);
  }
}
```
The TTL is critical — without it, a crashed process holding the lock would block everyone forever. A known subtlety (the Redlock debate) is that a single-Redis-instance lock isn't bulletproof against every failure mode, so genuinely correctness-critical locking combines this with fencing tokens or Redlock's stricter multi-instance protocol; for deduplicating a scheduled task across instances, the simple version above is sufficient.

Question 31

What is consistent hashing and why is it used in distributed caches?

Accepted Answer

Consistent hashing solves the problem of distributing keys across a set of nodes (cache servers, shards) in a way that minimizes redistribution when a node is added or removed. With naive hashing (`hash(key) % N`), changing N remaps almost every key to a different node — a cache with 100 servers that scales to 101 would see nearly all cache entries "miss" on their new server, a devastating cache stampede.

Consistent hashing instead maps both nodes and keys onto the same circular hash space (a ring); a key belongs to the first node found walking clockwise from its position on the ring. Adding or removing a node only reshuffles the keys between that node and its immediate neighbor on the ring — not the entire keyspace. In practice, each physical node is usually represented by many virtual nodes scattered around the ring to keep load balanced even with a small number of real servers. This is how memcached client libraries, DynamoDB's partitioning, and Cassandra's ring topology distribute data, specifically to avoid the "adding one server invalidates everything" problem.

Question 32

What's the difference between SQL and NoSQL databases, and when would you choose each?

Accepted Answer

SQL (relational) databases store data in tables with a fixed schema and enforce relationships via foreign keys, giving strong consistency, joins, and mature transaction support — the right default when data is naturally relational and you need strict correctness guarantees. NoSQL is an umbrella term for several models — document stores (MongoDB), key-value stores (DynamoDB, Redis), wide-column stores (Cassandra), and graph databases (Neo4j) — generally trading some consistency/join capability for horizontal scalability, flexible schema, and performance on specific access patterns.

The real decision isn't "SQL is old, NoSQL is modern" — it's about access patterns and consistency needs. A social media feed that needs to scale to millions of reads/writes with loosely structured data is a reasonable fit for a document store. A payments ledger that needs strict consistency and complex queries across related entities is a much better fit for a relational database. Many real systems use both — Postgres for the transactional core, Redis for caching, Elasticsearch for search — rather than picking one paradigm for everything.

Question 33

Explain database connection pooling and why it matters.

Accepted Answer

Opening a new database connection is expensive — it involves a TCP handshake, authentication, and on some databases spinning up a whole backend process (Postgres does this) — so doing it fresh for every request would add significant latency and could exhaust the database's max-connections limit under load. A connection pool keeps a set of already-open connections ready to be borrowed by a request and returned when done, instead of opening/closing one per request.

```javascript
const pool = new Pool({ max: 20, idleTimeoutMillis: 30000 });
const client = await pool.connect();
try {
  await client.query('SELECT * FROM users WHERE id = $1', [userId]);
} finally {
  client.release(); // returns to pool, doesn't close the connection
}
```
Sizing the pool matters: too small and requests queue up waiting for a free connection under load; too large and you risk overwhelming the database's own connection limit — especially dangerous with serverless functions, where a burst of concurrent invocations can collectively exceed the database's max connections even though each individual pool looks reasonable. That's why serverless architectures often front the database with a connection-pooling proxy (PgBouncer, RDS Proxy) rather than pooling per function instance.

Question 34

What does it mean for an HTTP method to be idempotent, and which methods are?

Accepted Answer

An idempotent HTTP method is one where making the same request multiple times has the same effect as making it once — the state of the resource after 1 call is identical to the state after N identical calls. GET, PUT, and DELETE are specified as idempotent: GET just reads and never changes state; PUT replaces a resource with the given representation, so doing it twice with the same body leaves the resource in the same final state; DELETE removes a resource, and deleting an already-deleted resource still ends with "resource doesn't exist" either way. POST is explicitly NOT idempotent by spec, because it typically means "create a new thing" — calling it twice usually creates two things.

This matters practically for retry safety: a client (or a proxy) can safely auto-retry a GET or PUT that timed out without asking the user, because repeating it is harmless, but auto-retrying a POST (like "create this order") risks creating a duplicate — exactly why POST endpoints needing retry-safety (payments, order creation) implement the idempotency-key pattern, bolting idempotency onto an operation that isn't naturally idempotent.

Question 35

How would you design API versioning for a public API?

Accepted Answer

API versioning lets you evolve an API's shape without breaking clients still calling the old version. The three common strategies are URL-path versioning (`/v1/users`, `/v2/users` — simplest, very visible, easy to route at the infrastructure level), header-based versioning (`Accept: application/vnd.myapi.v2+json` — keeps URLs clean but less discoverable), and query-parameter versioning (`/users?version=2` — rare, considered the weakest since it's easy to omit accidentally).

In practice, URL-path versioning dominates for public APIs (Stripe, GitHub, Twilio all use it) because it's unambiguous and cache-friendly — a CDN can route `/v1/*` and `/v2/*` to entirely different backend deployments without inspecting headers. The harder part isn't picking a scheme, it's the organizational discipline of maintaining backward compatibility within a version (only additive, non-breaking changes) and having a real deprecation policy (advance notice, sunset headers, a hard shutoff date) for retiring an old version.

Question 36

What is a webhook, and how does it differ from polling?

Accepted Answer

Polling means the client repeatedly asks the server "has anything changed yet?" at a fixed interval, whether or not there's actually new data — simple to implement, but wasteful and introduces up to one full polling-interval of latency before the client learns about a change. A webhook flips the direction: the server proactively sends an HTTP request to a URL the client registered in advance, the moment an event actually happens — no wasted requests, near-instant notification.

The trade-off is reliability and complexity: webhooks require the receiving endpoint to be publicly reachable (a problem behind NAT/firewall, or during local development — which is why tools like ngrok exist), and the sender needs retry logic with backoff for when the receiver is temporarily down, plus a way for the receiver to verify the webhook actually came from the claimed sender (a signature header, like Stripe's `Stripe-Signature`) rather than being spoofed. Polling remains the simpler, more robust default when near-real-time isn't required.

Question 37

What is the difference between authentication and authorization?

Accepted Answer

Authentication answers "who are you?" — verifying identity, typically via a password, a token, or a biometric. Authorization answers "what are you allowed to do?" — given a known identity, deciding whether that specific action on that specific resource is permitted. They're sequential and distinct: you always authenticate first, then authorize.

A concrete example: logging into an admin panel with a username/password is authentication — the system now knows you're "Alice." Whether Alice, once logged in, is allowed to delete a user or only view reports is authorization, typically enforced via roles or permissions checked on every sensitive action. A common real bug is conflating the two — checking only "is this user logged in?" before letting them hit an admin-only endpoint, without a separate check for "is this specific logged-in user actually an admin?" — which is how regular users end up able to call admin APIs just by being authenticated at all.

Question 38

What is SQL injection and how do you prevent it?

Accepted Answer

SQL injection happens when untrusted user input is concatenated directly into a SQL query string, letting an attacker craft input that changes the query's actual structure rather than just supplying a value. The classic example: a login query built as `"SELECT * FROM users WHERE username = '" + input + "'"` — if the attacker submits `' OR '1'='1`, the query becomes `SELECT * FROM users WHERE username = '' OR '1'='1'`, matching every row and potentially letting them log in as the first user in the table.

The fix is parameterized queries / prepared statements, where the query structure and the user-supplied values are sent to the database separately — the database treats the input strictly as data, never as executable SQL syntax.
```javascript
// vulnerable
db.query(`SELECT * FROM users WHERE username = '${input}'`);
// safe
db.query('SELECT * FROM users WHERE username = $1', [input]);
```
Every mainstream database driver/ORM supports parameterized queries, so in modern backend code SQL injection is almost always a symptom of someone hand-building a query string instead of using the driver's built-in parameter binding.

Question 39

Explain the difference between a monolith and microservices architecture, and the trade-offs.

Accepted Answer

A monolith is a single deployable application containing all the business logic, typically one codebase, one build, one deployment unit, usually one database. Microservices split that functionality into multiple independently deployable services, each owning its own piece of the domain, communicating over the network.

Monoliths are simpler to develop, test, and deploy early on — one codebase, no network calls between your own modules, easy to reason about a request end to end. Microservices offer independent scaling and deployment, but at real cost: network calls are slower and can fail in ways a function call can't, you need service discovery and distributed tracing, and data consistency across services becomes a genuine design problem (see the saga pattern). The pragmatic advice — start as a well-organized monolith and only split out services when a specific, real scaling or team-ownership pain point demands it — matches the general "don't add abstractions until you have two real use cases" principle, not splitting services because microservices are trendy.

Question 40

What is a health check endpoint, and what's the difference between liveness and readiness probes?

Accepted Answer

A health check endpoint tells an orchestrator (like Kubernetes) or a load balancer whether an instance of your service is healthy enough to receive traffic. Liveness and readiness are two distinct questions that get conflated if you only implement one health endpoint. Liveness asks "is this process alive and not deadlocked/hung?" — if it fails, the orchestrator kills and restarts the container, because a hung process won't recover on its own. Readiness asks "is this instance currently able to serve traffic well?" — if it fails, the orchestrator stops routing new requests to it but doesn't restart it, because the cause might be temporary and will resolve itself.

A concrete example: a service that lost its database connection is still "alive" (the process is fine, restarting won't fix a network problem) but shouldn't be "ready" (it can't serve real requests) — a combined health check would either wrongly restart a healthy process or wrongly keep sending it traffic it can't serve.

Question 41

Explain blue-green deployment vs canary deployment.

Accepted Answer

Blue-green deployment runs two identical production environments ("blue" = current live version, "green" = new version); you deploy the new version fully to green, verify it, then switch all traffic over atomically, keeping blue around to instantly roll back to if something's wrong. Canary deployment instead shifts traffic gradually — say 5% of real users to the new version first, watching error rates, then progressively increasing if things look healthy.

The trade-off: blue-green gives an instant, clean cutover and instant rollback, but every user hits the new version the moment you switch, so a bug affects 100% of traffic immediately if it slips through pre-switch verification. Canary limits the blast radius of a bad deploy to a small percentage of real users first, at the cost of more operational complexity (real traffic-splitting infrastructure and good real-time metrics). A "feature flag → gradual rollout → instant rollback" strategy is essentially a canary-style rollout applied at the feature level rather than the whole-deployment level.

Question 42

What is denormalization and when is it a good trade-off?

Accepted Answer

Normalization organizes data to avoid redundancy (each fact stored exactly once, related via foreign keys), which keeps writes consistent and storage efficient but often requires joining multiple tables to answer a read query. Denormalization deliberately duplicates some data to avoid those joins, trading write complexity for read performance.

A concrete example: an `orders` table might denormalize the customer's name directly onto each order row instead of always joining `customers`, so listing orders never needs a join — at the cost that if a customer changes their name, you either accept old orders showing the old name (often actually desirable — a historical record of the name at order time) or you need an update path to propagate the change. This is a good trade when reads vastly outnumber writes and the join cost is measurably hurting performance — not something to do preemptively "for speed" without a measured need.

Question 43

What is a thundering herd problem, and how do you mitigate it?

Accepted Answer

The thundering herd problem happens when a large number of clients/processes all wake up and hit the same resource at the same instant, overwhelming it — classic triggers are a popular cache key expiring (every request that would've hit cache now simultaneously falls through to the database to regenerate it) or many workers all polling on the same scheduled interval and firing at the exact same second.

The standard mitigations: for cache expiry, use "cache stampede protection" — either have only one request regenerate the value while others wait for it (a lock around regeneration, or probabilistic early expiration where requests near the expiry time have a small chance of proactively refreshing before it actually expires), or serve slightly stale data while one background refresh happens. For synchronized scheduled jobs, add jitter to the schedule/retry delay so requests spread out over a window instead of firing all at once. Both fixes break the synchronization that made many independent actors act at exactly the same moment.

Question 44

What is write skew, and why can it happen even under snapshot isolation in Postgres?

Accepted Answer

Write skew is a subtle correctness bug that can happen even under snapshot isolation (which Postgres uses for its default Repeatable Read, and which many people assume prevents all concurrency anomalies). It occurs when two transactions each read overlapping data, each makes a decision based on what they read, and each writes to a *different* row — so neither transaction's write actually conflicts with the other's write at the row level, meaning the database's conflict detection doesn't catch it, yet the combined effect of both transactions violates an invariant that depends on both rows together.

The textbook example: a hospital rule requires at least one doctor on call at all times. Two doctors, Alice and Bob, are both on call. Each independently checks "are there at least 2 doctors on call right now?" — yes — and decides it's safe to take themselves off call. Both transactions read the same snapshot (2 doctors on call), both see the invariant satisfied, and both commit their own separate write without conflicting with each other's row. The result: zero doctors on call, violating the invariant, even though neither individual transaction's data was ever "wrong" in isolation.

```sql
BEGIN;
SELECT count(*) FROM doctors WHERE on_call = true; -- Alice sees 2, Bob sees 2
UPDATE doctors SET on_call = false WHERE name = 'Alice';
COMMIT;
```
The fix requires explicitly serializing the check-then-act, either by using `SELECT ... FOR UPDATE` to lock the rows the invariant depends on, or by running that transaction under `SERIALIZABLE` isolation, which Postgres implements via serializable snapshot isolation — detecting exactly this class of anomaly and aborting one of the conflicting transactions rather than letting both commit.

Question 45

Explain two-phase commit (2PC) and its main weakness.

Accepted Answer

Two-phase commit is a protocol for atomically committing a transaction across multiple independent resources (e.g., two different databases, or a database and a message queue) so that either all of them commit or all of them roll back. Phase one (prepare): a coordinator asks every participant "can you commit this?" and each participant does all the work needed to guarantee it CAN commit (writes to its own log) and replies yes/no, without actually committing yet. Phase two (commit): if every participant said yes, the coordinator tells them all to actually commit; if any said no, it tells them all to roll back.

The main weakness is that 2PC is a blocking protocol: if the coordinator crashes after phase one but before sending the phase-two commit message, every participant is stuck holding its locks indefinitely, unable to safely decide on its own whether to commit or abort, until the coordinator recovers. This is why most modern distributed systems avoid 2PC for anything needing high availability and instead favor the saga pattern, which sacrifices atomicity for availability and much better failure characteristics — 2PC still shows up in specific contexts like XA transactions within a single data center, but it's rare in internet-scale distributed systems.

Question 46

What is a bloom filter, and where might a backend use one?

Accepted Answer

A bloom filter is a probabilistic data structure that answers "is this element possibly in the set?" using far less memory than storing the actual set, at the cost of allowing false positives (it might say "probably in the set" for something that isn't) but never false negatives (if it says "definitely not in the set," that's always true). It works by hashing an element with several independent hash functions, each pointing to a bit in a shared bit array, and setting all those bits to 1 on insert; checking membership just checks whether all those bits are set — if even one is 0, the element is definitely not in the set.

A concrete backend use case: a database like Cassandra or RocksDB wants to avoid an expensive disk lookup for a key that almost certainly doesn't exist — it checks an in-memory bloom filter for each on-disk file first, only falling through to the actual disk read for the small fraction of true-and-false positives. Web crawlers use the same trick to cheaply check "have I already visited this URL?" without storing every URL in full. It only pays off at a scale where avoiding I/O actually matters, which is why most engineers know the phrase without ever having needed to reach for one.

Question 47

What is backpressure in a streaming or queue system, and how do you implement it?

Accepted Answer

Backpressure is a mechanism for a fast producer to not overwhelm a slower consumer in a streaming or queue-based pipeline — without it, if a producer generates data/work faster than the consumer can process it, the excess has to go somewhere (an ever-growing in-memory buffer), eventually exhausting memory and crashing the process.

Implementations vary by layer: in a message queue, backpressure is usually a bounded queue — once it's full, the producer either blocks or explicitly gets an error/rejection it can react to. In a streaming API (Node.js streams, reactive streams in Java), the consumer explicitly signals how much it's ready to receive, and the producer only sends that much.

```javascript
readableStream.on('data', (chunk) => {
  const canContinue = writableStream.write(chunk);
  if (!canContinue) readableStream.pause(); // backpressure: consumer signals "slow down"
});
writableStream.on('drain', () => readableStream.resume());
```
Concretely, this is exactly why piping a large file read stream into a slow network write stream in Node.js should use `.pipe()` (which handles this pause/resume dance automatically) rather than manually reading all data into memory and writing it — the latter has no backpressure at all and can OOM on a large enough file.

Question 48

Explain the difference between WebSockets, Server-Sent Events, and long polling.

Accepted Answer

Long polling is the simplest real-time-ish technique: the client makes a normal HTTP request, but the server holds it open without responding until it actually has new data (or a timeout hits), then the client immediately opens a new request — still fundamentally request/response, just with the server delaying the response, and it works over plain HTTP. Server-Sent Events (SSE) is a real one-way streaming protocol built into browsers (`EventSource`): the server keeps one HTTP connection open and pushes text-based events down it whenever it wants, and the browser automatically reconnects if the connection drops — good for server-to-client-only updates with far less overhead than repeated long-polling requests. WebSockets provide a genuine full-duplex connection — both client and server can send messages at any time over one persistent connection — needed when the client also needs to push frequent messages back (chat, multiplayer games), which neither long polling nor SSE support in that direction.

The practical choice: use long polling only when you can't use anything better (some restrictive proxies block WebSocket upgrades); use SSE when updates only flow server-to-client (a live dashboard, a notification feed) since it's simpler than WebSockets; use WebSockets when you genuinely need bidirectional, low-latency communication.

Question 49

What is leader election in a distributed system, and how do tools like etcd or Zookeeper help?

Accepted Answer

Leader election is the problem of getting a group of distributed nodes to agree on exactly one of them being "the leader" responsible for some coordinating role (e.g., the one node allowed to schedule jobs, or the primary database node accepting writes), even though nodes can crash and the network can partition — and critically, avoiding a "split brain" where two nodes both believe they're the leader simultaneously.

Tools like etcd and Zookeeper solve this via an underlying consensus protocol (Raft for etcd, ZAB for Zookeeper) that guarantees a majority of nodes agree on any state change, including who the current leader is. In practice, a service does leader election by trying to acquire a lease/lock in etcd/Zookeeper with a TTL; whichever node acquires it becomes leader and must periodically renew the lease, and if it crashes or gets network-partitioned, the lease expires and another node acquires it and becomes the new leader. A concrete example: Kubernetes itself uses leader election (backed by an etcd lease) among its controller-manager replicas so only one is actively reconciling cluster state at a time, even though multiple replicas run for high availability.

Question 50

What is the difference between a process and a thread, and why does it matter for backend concurrency models like Node.js's event loop vs Java's thread-per-request?

Accepted Answer

A process has its own isolated memory space; a thread is a unit of execution within a process that shares that process's memory with other threads in the same process, which makes inter-thread communication cheap but also introduces race conditions if two threads touch the same data without coordination — a problem two separate processes don't have unless they explicitly set up shared memory.

This distinction shapes two very different backend concurrency models. Java's traditional thread-per-request model spins up an OS thread per incoming request; each request gets true parallelism on multi-core hardware, but each thread carries real memory overhead, so a server handling tens of thousands of concurrent slow (I/O-bound) requests can run out of threads/memory even though the CPU is mostly idle waiting on I/O. Node.js instead runs JavaScript on a single thread with an event loop: I/O operations are handed off to the OS/libuv's thread pool and the main thread moves on to handle other requests while waiting, invoking a callback when the I/O completes — this lets one thread handle huge numbers of concurrent I/O-bound requests cheaply, but a single CPU-bound task blocks that one thread and stalls every other request being served by that process, which is why CPU-heavy work in Node is typically offloaded to a worker thread or a separate process rather than run inline.

Question 51

What is middleware in a backend framework like Express, and why is it used?

Accepted Answer

Middleware is a function that sits in between an incoming request and the final route handler, getting a chance to inspect, modify, or reject the request before it reaches your actual business logic. Each middleware function receives the request and response objects plus a `next` function, and it must call `next()` to pass control along to the next middleware or route handler in the chain — if it doesn't call `next()` (or send a response itself), the request just hangs forever.

The reason middleware exists is to avoid repeating the same cross-cutting logic in every single route. Instead of writing "check if the user is logged in" inside every route handler, you write it once as middleware and attach it to whichever routes need it. Common examples are logging every incoming request, parsing the JSON request body, checking authentication, and validating input — all before the route's own code even runs.

```javascript
function requireAuth(req, res, next) {
  if (!req.headers.authorization) {
    return res.status(401).json({ error: 'Not logged in' });
  }
  next(); // move on to the actual route handler
}

app.get('/profile', requireAuth, (req, res) => {
  res.json({ name: 'Alice' });
});
```

If a request hits `/profile` without an `authorization` header, `requireAuth` sends the 401 response itself and never calls `next()`, so the route handler below it never runs at all — this is the whole point of chaining middleware, letting you reuse the same check across as many routes as you want.

Question 52

What are HTTP status codes, and what do the main categories (2xx, 3xx, 4xx, 5xx) mean?

Accepted Answer

An HTTP status code is a three-digit number the server sends back with every response, telling the client (browser, mobile app, another server) what happened to its request — whether it succeeded, needs a redirect, was invalid, or the server itself broke. Rather than the client having to guess from the response body, the status code gives a standardized, machine-readable summary that tools like browsers, HTTP libraries, and monitoring systems all understand the same way.

The codes are grouped by their first digit. 2xx means success — the most common is 200 OK, but 201 Created is used specifically after creating a new resource (like a new user or order), and 204 No Content means it succeeded but there's nothing to send back. 3xx means redirection — the client needs to look somewhere else, like 301 Moved Permanently. 4xx means the client made a mistake — 400 Bad Request for malformed input, 401 Unauthorized when you're not logged in, 403 Forbidden when you're logged in but not allowed to do that action, and 404 Not Found when the resource doesn't exist. 5xx means the server itself failed — 500 Internal Server Error is the generic "something broke on our end" code.

```javascript
app.get('/users/:id', (req, res) => {
  const user = findUser(req.params.id);
  if (!user) return res.status(404).json({ error: 'User not found' });
  res.status(200).json(user);
});
```

Getting these right matters beyond convention — a frontend might auto-retry on a 5xx (assuming it's a temporary server problem) but never retry on a 4xx (since retrying the exact same bad request will just fail again the same way), so picking the wrong code can genuinely break how clients behave.

Question 53

What is the difference between an INNER JOIN and a LEFT JOIN in SQL?

Accepted Answer

A JOIN combines rows from two tables based on a matching column, usually a foreign key. An INNER JOIN only returns rows where a match exists in both tables — if a row in one table has no corresponding row in the other, it's left out of the result entirely. A LEFT JOIN (short for LEFT OUTER JOIN) returns every row from the left (first) table regardless of whether a match exists in the right table, filling in NULLs for the right table's columns when there's no match.

A concrete example: imagine a `customers` table and an `orders` table, where not every customer has placed an order yet.

```sql
-- INNER JOIN: only customers who have at least one order show up
SELECT customers.name, orders.id
FROM customers
INNER JOIN orders ON customers.id = orders.customer_id;

-- LEFT JOIN: every customer shows up, even ones with zero orders (orders.id is NULL for them)
SELECT customers.name, orders.id
FROM customers
LEFT JOIN orders ON customers.id = orders.customer_id;
```

You'd reach for INNER JOIN when you only care about records that genuinely relate to both tables — like a report of "orders and which customer placed them." You'd reach for LEFT JOIN when you need to keep every row from one side no matter what — like "show me all customers, and flag which ones have never ordered anything," where a customer with no matching order row would simply vanish from an INNER JOIN's results, which isn't what you want.

Question 54

What are environment variables, and why shouldn't you hardcode things like API keys or database passwords in your code?

Accepted Answer

An environment variable is a value set outside your code — in the operating system, a hosting platform's dashboard, or a local `.env` file — that your application reads at runtime instead of having the value written directly into the source code. Backend apps commonly use them for things like database connection strings, third-party API keys, and which mode the app is running in (development vs production).

Hardcoding a secret like an API key directly into a source file is a real security problem: that file gets committed to git, and git history keeps every past version forever, so even deleting the key later doesn't remove it from history — anyone with repo access (or anyone who finds a leaked/public repo) can read it. Environment variables keep secrets out of the codebase entirely, so the same code can be safely open-sourced, reviewed, or shared while the actual secret values live only in each environment's private configuration.

```javascript
require('dotenv').config(); // loads variables from a local .env file (which is gitignored, never committed)

const dbPassword = process.env.DB_PASSWORD;
const apiKey = process.env.STRIPE_API_KEY;
```
```
# .env (never committed to git)
DB_PASSWORD=s3cr3t123
STRIPE_API_KEY=sk_live_abc123
```

This also solves a second problem beyond security: the same code needs different values in different places — a local dev database password isn't the same as the production one — and environment variables let one unchanged codebase behave correctly in every environment just by swapping the underlying config, rather than editing code each time you deploy.

Backend Interview Questions & Answers

Ready to practice these live?