Async workload router
HTTP/event ingress → event loop → queue → worker → realtime channel → storage/external service.
Choose API, worker, or realtime paths deliberately so CPU-heavy work does not silently block I/O concurrency.
Primary intent: Asynchronous Node.js service platforms and real-time/integration workloads
Choose API, realtime, or worker workload to see the recommended processing path and tradeoff.
Choose API, realtime, or worker workload to see the recommended processing path and tradeoff.
Static map: ingress → event loop → queue/worker or realtime channel → storage/external service.
Request/response service with outbound I/O.
Tradeoff: Do not run CPU-heavy transforms inline without a worker.
Node.js is the runtime and async platform. Express/Nest are frameworks that may run on it—do not reduce this page to routing.
Illustrative delivery shapes—not a guaranteed catalog.
HTTP services with explicit timeout and backpressure strategies.
Background processors for email, sync, and enrichment jobs.
Websocket/event fanout with auth and connection lifecycle care.
How request, domain, and operational paths typically separate.
HTTP/event ingress → event loop → queue → worker → realtime channel → storage/external service.
Heavy CPU work needs workers or another runtime—Node is not a free parallel compute engine.
Process managers, memory limits, and dependency updates are part of delivery—not afterthoughts.
Portfolio links show related platform capability. They do not assert Node.js was used in every referenced delivery.
No fake concurrency percentages or always-prefer-Node claims.
Worker threads and child processes exist, but the default model is an event loop optimized for concurrent I/O—not automatic parallel CPU scaling.
If you need framework structure, yes. This page is about runtime workload design—event loop, queues, realtime, and operations.
Describe API, worker, and realtime needs—we will map an async architecture you can operate.
Begin stack consultation