Node.js Developer interview questions

I would keep one deployment but make each module a separately enforced ownership boundary in code and data access.

• Order, Inventory, and Billing would expose narrow TypeScript entry points, while package exports, project references, and dependency-cruiser or ESLint rules reject imports of internal files.
• Each module would own its PostgreSQL tables and repository; another module calls its public API instead of issuing 1 of the 7 direct writes or joining private tables in application code.
• CI would fail on any of the 18 forbidden dependency edges, run contract tests against public entry points, and publish a dependency graph so boundary drift is visible before merge.
• Cross-module work that must share one database transaction would run through an explicit application coordinator using module APIs, while noncritical side effects use typed in-process events with named owners.

I would give Order and Inventory separate ownership and replace the shared transaction with an explicit stock-reservation workflow.

• Order owns the order state and total, while Inventory alone owns available quantity and a reservation with an order ID and a 10-minute expiry.
• Checkout creates a Pending order, sends ReserveStock with the order ID, and confirms only after Inventory returns a durable reservation, so no service writes another context's tables.
• A rejected or expired reservation cancels the Pending order, while duplicate reserve and release commands use the same order ID and a uniqueness constraint.
• If the business requires order creation and stock decrement to commit in 1 atomic step with no Pending state, I would keep that invariant in 1 context rather than introduce 2PC.

I would keep the decisions needed for the customer's confirmation synchronous and publish post-confirmation work to Kafka.

• The browser uses HTTP JSON, while internal pricing, inventory, and payment can use gRPC if generated Protobuf contracts already exist; changing protocols alone will not recover a bad latency budget.
• I would allocate about 50 ms to the edge and app, 80 ms to pricing, 120 ms to inventory, 180 ms to payment, and keep 70 ms for network variance and serialization.
• After the order commits, a transactional outbox publishes OrderConfirmed to Kafka within 1 second for fulfillment, email, and analytics, none of which should consume the 500 ms response budget.
• If payment cannot finish inside its 180 ms share, I would return a Pending result and complete it asynchronously rather than build a synchronous chain that routinely exceeds 500 ms.

I would keep uniform edge controls in the gateway and enforce resource-level authorization in the service that owns the order.

• The gateway terminates TLS, validates JWT signatures from a cached JWKS, routes requests, caps bodies at 2 MB, applies per-client rate limits, and emits low-cardinality traffic metrics.
• At 100,000 RPS, gateway replicas must stay stateless and avoid a user or policy database lookup on every request; cached keys and local token checks keep the edge scalable.
• The gateway may require an orders:read scope, but the Order service checks that the caller owns order 8472 or has the tenant-specific support permission using current domain data.
• I would not put checkout orchestration, order-state transitions, or service-specific response mapping in the gateway, because 3 such features already create a coupled deployment bottleneck.

I would use Kubernetes for discovery and balance at the gRPC stream level rather than by TCP connection count.

• A Service plus EndpointSlices or xDS exposes the 40 ready pods, while clients maintain several HTTP/2 channels and use round robin across resolved endpoints instead of one DNS-pinned channel.
• An L7 gRPC proxy should choose an upstream by active requests or streams, not least TCP connections, because one connection can carry thousands of the 80,000 concurrent streams.
• Readiness removes a pod from new endpoint selection, but it cannot stop new streams on an existing channel; draining must also invoke grpc-js server.tryShutdown or send GOAWAY and reject new calls.
• I would allow 60 seconds for cooperative stream completion, then force shutdown, while a jittered maximum connection age gradually refreshes channel distribution without synchronizing all clients.

I would use an orchestrated saga with durable state because 4 ordered steps and their compensations need one visible workflow record.

• The orchestrator persists checkout ID, current step, attempt count, and a 15-minute deadline, then sends each command through an outbox after its local transaction commits.
• On failure it compensates in reverse order: cancel shipment, void the payment authorization, release stock, and mark the order Cancelled.
• Every forward and compensation command uses a key such as checkout-482:reserve-stock, and each service atomically records that key with its local mutation before acknowledging.
• A timeout retries transient failures at most 3 times, then moves the saga to ManualReview if a compensation such as voiding payment cannot be confirmed.

I would carry one stable operation identity through all 3 services and give each side effect its own deterministic child key.

• Checkout stores tenant ID, endpoint, idempotency key, a SHA-256 request fingerprint, state, and response under a unique constraint before starting work.
• It derives separate keys such as key-731:payment and key-731:shipment, so all 4 retries reach the same downstream operations without conflating 2 different effects.
• Each service claims its key and applies its business mutation in 1 local transaction; a concurrent duplicate returns the stored result or a 202 Pending response.
• I would retain keys for 7 days, longer than the HTTP retry and message replay windows, and reject the same key with a different fingerprint as a 409 conflict.

I would expand the provider first, migrate the 12 consumers independently, and contract only after telemetry proves the old field is unused.

• In week 1 the provider accepts customerName or the new structured customer field, returns both representations, and normalizes them into 1 domain model at the API boundary.
• Consumer-driven contract tests run both shapes in CI, and every request records consumer ID and contract version so an unregistered caller cannot disappear from the migration count.
• I would move about 2 consumers per week without a synchronized release, publish a generated client for the new shape, and keep rollback compatible with the expanded provider.
• After all 12 consumers migrate and old-field usage remains at 0 for 14 days, I would stop returning it, then remove acceptance and adapter code in a later release.

I would fit the entire resilience policy inside 600 ms instead of assigning each attempt an independent timeout.

• I would reserve 100 ms for application work, 120 ms for the database, 80 ms for response variance, and give the dependency at most 300 ms in total.
• With a measured dependency p99 near 90 ms, I would start with a 140 ms attempt timeout and allow 1 retry after up to 20 ms of jitter only for idempotent calls and transient errors.
• The propagated deadline cancels downstream work, and no retry starts unless at least 160 ms remains, so an expired caller cannot create useful-looking background load.
• I would start the breaker at 50% eligible failures over at least 20 calls, open it for 5 seconds, permit 2 half-open probes, and tune those numbers from traffic rather than guesswork.

I would isolate recommendation capacity from the core product path and omit recommendations before they can exhaust the 60 database connections.

• Core product reads keep the 60-connection PostgreSQL pool, while recommendations get a separate HTTP agent with 20 sockets, a concurrency limit of 40, and a bounded queue of 80 requests.
• The optional call gets an 80 ms timeout and no in-request retry; on failure the API returns the product with a recommendationStatus of unavailable or a Redis value no older than 5 minutes.
• Once the 80-slot optional queue is full, new recommendation work is skipped immediately, so 12,000 RPS cannot turn a slow dependency into unbounded promises and heap growth.
• I would graph core latency, skipped recommendations, queue depth, socket use, and stale-cache age separately, then verify under load that recommendation failure does not move product p95 above 250 ms.

I would run 18 one-core process replicas, six on each of three 8-core hosts; at 24,000 RPS each normally handles about 1,333 RPS and rises to 2,000 RPS after one host fails.

• One JavaScript event loop uses one core for application code, so additional processes, not one larger process, expose the other cores.
• The 2,000 RPS target is 67% of the measured 3,000 RPS limit, leaving event-loop and traffic-burst headroom.
• Losing one host leaves 12 replicas and exactly 24,000 RPS of planned capacity, while two spare cores per host cover the OS and native work.
• I would externalize state and load-test the database, cache, connection pools, and network at 36,000 RPS because process capacity is not end-to-end capacity.

I would normally run 24 one-process pods with a 1 vCPU request instead of nesting four cluster workers inside each of six pods.

• Kubernetes can schedule, health-check, restart, and drain each process independently rather than treating four failure and memory domains as one pod.
• Per-pod CPU, RSS, event-loop delay, and readiness then describe one Node.js process, which makes limits and autoscaling signals easier to interpret.
• A rolling update can replace a few of 24 processes at a time, while a six-pod cluster layout removes four processes whenever one pod is replaced.
• I would keep cluster for a standalone 4-core VM or a platform without process orchestration, and document any exception caused by unusually expensive sidecars or per-pod resources.

I would use weighted least-connections for WebSocket upgrades and least-outstanding-requests or round robin for the short HTTP traffic.

• Least-connections steers each new upgrade toward the replica with fewer open sockets, keeping the expected 5,000 sockets per replica below the measured 6,000 limit.
• I would not let the 20,000 long-lived sockets dominate the HTTP decision, so the load balancer needs separate counters or backend pools for upgrades and ordinary requests.
• Weighted routing can reduce traffic to a smaller or warming replica, while consistent hashing is unnecessary unless an explicit locality requirement remains after state is externalized.
• Readiness must reject new upgrades before a replica drains, while existing sockets stay on their current replica until close or a bounded deployment deadline.

I would avoid sticky routing for HTTP, externalize session and messaging state, and accept affinity only for each WebSocket while that connection is open.

• An opaque session ID can reference Redis state with a 30-minute TTL, allowing any of the six replicas to authenticate the next HTTP request.
• A shared connection registry and partitioned pub-sub route messages to the replica holding a socket, with an expected average of 10,000 sockets per replica.
• Cookie or source-IP stickiness can hide in-memory state, but it creates load skew and loses continuity when a selected pod is replaced during the rollout.
• Clients should reconnect with jitter and a resume cursor so replacement moves a connection safely without requiring the old process memory to survive.

I would reserve the remaining 25 ms as 10 ms for event-loop queueing, 10 ms for application work, and 5 ms of safety margin, while keeping any single synchronous chunk below 5 ms.

• At 400 RPS, 1.5 ms of synchronous work demands about 600 ms of one core per second, so the process starts near 60% event-loop utilization before callbacks and garbage collection.
• I would record monitorEventLoopDelay as a histogram and require its p99 to stay below the 10 ms queueing allocation under the real request mix.
• I would compare eventLoopUtilization snapshots over load windows and investigate sustained values above roughly 70%, rather than treating one cumulative value as a request metric.
• CPU profiles identify chunks exceeding 5 ms, which I would bound, split with scheduled yields, or move to a worker pool before retesting the 120 ms p99.

I would use six worker threads per pod, deploy at least two replicas, and transfer each 8 MiB ArrayBuffer rather than clone it.

• Six workers provide a theoretical 150 jobs per second, and a 70% operating target gives about 105 jobs per second while leaving CPU for the main event loop and native work.
• Two replicas provide about 210 jobs per second at that target, and a bounded input queue must reject or defer work when arrivals exceed it.
• Transferring the ArrayBuffer moves its backing store and detaches it from the sender, while cloning 200 inputs per second would copy about 1.6 GiB per second before result traffic.
• If the sender must retain the bytes, I would make that copy explicit or design a synchronized SharedArrayBuffer protocol, then benchmark computation, messaging, RSS, and p99 together.

I would start with UV_THREADPOOL_SIZE=4, cap password derivation at three concurrent operations per replica, and benchmark before increasing the pool.

• The crypto load consumes about 2.4 core-seconds per second per replica, so a much larger pool cannot create CPU capacity on a 4 vCPU limit.
• Three concurrent 40 ms operations provide a theoretical 75 per second and leave one pool slot for filesystem, dns.lookup, zlib, or other shared libuv work.
• A size of 4 creates 48 libuv threads across 12 replicas, while setting 16 would create 192 threads and can add context switching and memory without raising useful throughput.
• I would compare sizes 4, 6, and 8 using crypto queue time, filesystem p99, CPU, and RSS, and isolate password work in separate replicas if the shared pool still violates either SLO.

The microtask chain is starving timer and I/O phases because Node.js keeps draining microtasks before the event loop can advance.

• Promise.then and queueMicrotask schedule more microtasks, so replacing recursion with either API does not yield; recursive process.nextTick is even more aggressive because its queue runs before ordinary promise microtasks.
• I would process a measured chunk such as 500 items, save the cursor, and await setImmediate from node:timers/promises before the next chunk so timers and poll callbacks can run.
• If the 100,000 steps are CPU-heavy rather than short coordination work, I would send the batch to a bounded worker_threads pool instead of creating a longer sequence of event-loop turns.
• A load test would track monitorEventLoopDelay p99, eventLoopUtilization, timer lateness, throughput, and queue depth and keep the chunk size only if the 10 ms timer stays within its budget.

I would start with --max-old-space-size=1024, budget each replica at the full 2 GiB limit, schedule at most six such pods per 16 GiB node, and take heap snapshots only in an isolated diagnostic replica.

• RSS is the capacity number because it includes V8 heap, Buffers, native allocations, code, and thread stacks; the measured 1.6 GiB peak leaves only about 400 MiB below the pod limit.
• Six 2 GiB pod limits reserve 12 GiB and leave 4 GiB for the operating system, Kubernetes, daemons, and transient node pressure.
• A snapshot can stop the event loop and require substantial extra memory, so I would remove a replica from traffic and give the diagnostic pod at least 3 GiB rather than risk an OOM in a 2 GiB production pod.
• I would compare warmed post-GC snapshots by retained size and retaining path, then verify the fix with RSS slope, GC time, and a soak test instead of raising the heap limit alone.

I would make the load balancer retire idle connections first, bound slow request ingestion separately, and enforce the 2-second handler budget with cancellation.

• I would set server.keepAliveTimeout near 55 seconds so the load balancer, which owns and reuses the client side of the upstream connection, closes it at 50 seconds before Node.js reaches its server-side idle timeout.
• I would start with headersTimeout at 10 seconds and requestTimeout at 20 seconds for the complete 2 MiB request, plus header-count and body-size limits so slow clients cannot occupy parsers indefinitely.
• The route would use an AbortController with a deadline below 2 seconds and pass its signal to fetch, database acquisition, and streamed work, because server socket timeouts do not cancel application promises automatically.
• I would align the client agent and proxy settings in a load test and monitor connection resets, 408 responses, active sockets, reuse rate, and p99 before changing the 55, 10, or 20 second values.