Concurrency Interview Questions for Backend Developers

Model answer

A race condition is a bug where the result depends on the timing of two things running at once.

count++ looks like one step but is three: read count, add 1, write it back. Two threads both read 5, both compute 6, both write 6. Two increments, one counted. Run it a million times on two threads and the total comes out short, by a different amount each run.

Races are hard to find because they only show up under load or on certain timings, and adding logging can make them disappear.

Model answer

A lock (mutex, synchronized) makes the read-add-write a critical section that one thread enters at a time.

An atomic operation does the read-modify-write as one indivisible CPU instruction (compare-and-swap): AtomicInteger.incrementAndGet() in Java, atomic.AddInt64 in Go.

For a single counter, choose the atomic: no blocking, no risk of forgetting to unlock, faster under contention. Use a lock when several values must change together (move money between two balances), which one atomic cannot cover.

Model answer

Each server has its own memory, so its lock only protects its own threads. Move the atomicity to the shared store:

• An atomic update in SQL: UPDATE counters SET value = value + 1 WHERE id = ?. The database serialises it. Simplest, and usually enough.
• Optimistic locking: read the row with its version, write WHERE version = ?, retry if nothing changed. Good when conflicts are rare.
• Pessimistic locking: SELECT ... FOR UPDATE inside a transaction when the logic between read and write is complex.
• Redis INCR when the counter is hot and does not need to live in the database.

For very hot counters (likes, views), keep several sharded counter rows and sum them on read, so writes do not all fight over one row.

Model answer

• The holder pauses past the expiry: a long GC pause or slow network makes the job run longer than 30 seconds, the lock expires, a second worker takes it, and now two run at once. Nothing on the first worker notices.
• Deleting someone else's lock: worker A finishes late and runs DEL, removing the lock worker B now holds. Store a random token as the value and delete only if it still matches, in one Lua script.
• Failover: the Redis primary acknowledges the lock and dies before replicating it; the new primary has no lock.

If correctness depends on the lock, use fencing tokens: the lock service hands out an increasing number, the worker sends it with every write, and the storage rejects writes with a number lower than one it has seen. Or let the database do the locking (a row lock, Postgres advisory locks), which is where the data lives anyway.

A Redis lock is fine for efficiency ("avoid doing the work twice"), not for correctness ("must never happen twice").

Model answer

Most of a web request is waiting: on the database, on another API, on the disk. Node does not block a thread while waiting. It starts the I/O, registers a callback, and moves on to the next request.

The operating system (epoll, kqueue, IOCP) reports when sockets are ready, and libuv's event loop runs the matching callbacks one at a time. File system work and some crypto go to libuv's small thread pool (4 threads by default).

So one thread can juggle thousands of connections, as long as no callback holds the thread for long.

Model answer

Resizing is CPU work, so it runs on the one JavaScript thread and blocks the event loop. Until it finishes, no other callback runs: other requests, timers and health checks all wait.

Fixes:

• Move it to worker threads (worker_threads, or a pool such as Piscina), so it runs on another core.
• Use a library that does the work in native code off the main thread (sharp uses libuv's thread pool).
• Better still for heavy work: put a job on a queue and let a separate worker service process it, returning the result later.

Watch event loop lag as a metric (perf_hooks.monitorEventLoopDelay) to spot this before users do.

Model answer

After the current code finishes, Node first empties the nextTick queue, then the promise microtask queue. Both run before the event loop moves on. Then come the event loop phases: timers (setTimeout) and later check (setImmediate).

setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));
Promise.resolve().then(() => console.log('promise'));
process.nextTick(() => console.log('nextTick'));
// nextTick, promise, then timeout and immediate

The catch: from the main module, timeout and immediate can come in either order, depending on whether the 1 ms timer is due when the loop starts. Inside an I/O callback, setImmediate always runs first, because the check phase comes right after the poll phase.

A recursive process.nextTick starves the event loop: I/O never gets a turn.

Model answer

Async makes starting work cheap, so nothing slows it down: Promise.all(items.map(fetch)) over 5,000 items fires 5,000 queries at once. Each new request does the same. The database has a hard connection limit and each connection costs it memory.

Bound it:

• A connection pool with a fixed maximum (say 10 to 20 per instance), sized so instances times pool size fits the database limit. Extra queries wait in the pool's queue.
• Limit concurrency in code with a semaphore (p-limit): at most N tasks in flight.
• Put PgBouncer (or RDS Proxy) in front when there are many instances.
• Add backpressure: when the queue is long, reject with 503 quickly instead of letting latency grow without end.

Model answer

A thread pool keeps a fixed set of threads and feeds them tasks from a queue.

A platform thread is expensive: roughly 1 MB of stack reserved, an OS scheduling entry, and time to create. A thread per request works until a traffic spike creates 10,000 threads, the machine spends its time switching between them, and it runs out of memory.

A pool caps how much work runs at once and reuses threads. In Java that is ExecutorService, typically a ThreadPoolExecutor.

Model answer

It grows to corePoolSize threads, then queues tasks, then, only once the queue is full, adds threads up to maximumPoolSize, then rejects with the RejectedExecutionHandler (the default AbortPolicy throws).

The trap: Executors.newFixedThreadPool uses an unbounded queue, so it never rejects. Under overload the queue grows until memory runs out, and every task waits longer and longer, timing out after its caller has given up.

Prefer a bounded queue and a deliberate rejection: fail fast with a 503, or CallerRunsPolicy, which makes the submitting thread run the task and so slows producers down (backpressure).

Model answer

• Timeouts on every outbound call (connect and read), set from the dependency's normal latency, never the library default, which is often infinite.
• Bulkheads: give each dependency its own small pool or semaphore, so the slow one can only use up its own threads, not the ones serving everything else.
• A circuit breaker (Resilience4j): after enough failures, stop calling for a while and fail immediately, then let a few test calls through.
• A fallback where it makes sense: cached data or a degraded response.

The principle: a failure in one dependency should cost you that feature, not the whole service.

Model answer

Virtual threads are cheap enough to have one per task, even millions, and blocking one costs almost nothing: the JVM parks it and frees its carrier thread. So you no longer pool threads to save threads; Executors.newVirtualThreadPerTaskExecutor() is the normal style.

You still need to limit resources: a million virtual threads will happily open a million database connections. Use a semaphore or a sized connection pool to cap concurrent access to each dependency. Bulkheads and timeouts are as necessary as before.

Watch for pinning: on JDK 21 to 23, a virtual thread that blocks inside a synchronized block holds on to its carrier thread (fixed in JDK 24). CPU-bound work gains nothing from virtual threads either.