Scaling a Node.js Service

13 questions

A single Node process runs your JavaScript on one event-loop thread — so scaling it is a system-design problem, not a config flag. Build intuition for statelessness as the precondition for horizontal scaling, cluster vs. worker_threads, moving shared state into Redis, why sticky sessions are a smell, graceful shutdown and connection draining on SIGTERM, liveness vs. readiness probes, and keeping CPU-bound work off the event loop. Code snippets and the libuv thread-pool facts are verified against current Node.

Start

Questions

Not answered. Why do users get randomly logged out after scaling to three instances?
Not answered. Which tool idiomatically moves CPU-bound work off the event loop?
Not answered. Which statements about cluster vs. worker_threads are true?
Not answered. How does cluster distribute incoming TCP connections by default?
Not answered. Where should the shared session state live?
Not answered. Which of these are genuine drawbacks of sticky sessions?
Not answered. What should a Node process do on SIGTERM to shut down gracefully?
Not answered. Why does server.close() hang even with no requests in flight?
Not answered. How do failing liveness and readiness probes differ in Kubernetes?
Not answered. What should a Pod do first when it receives SIGTERM?
Not answered. While one /report request runs, what happens to other requests?
Not answered. How many threads does libuv's thread pool have by default?
Not answered. Which signal asks a container to shut down gracefully?