The loop sits on top of an operating system feature for watching many file descriptors at once. On Linux that is epoll, on macOS and BSD it is kqueue, on Windows it is IOCP. You hand the kernel a list of sockets you care about and it tells you, in one call, which ones are ready. This is why the cost stays flat as connections grow instead of one syscall per socket.
Node.js builds this with a C library called libuv. libuv runs the loop in distinct phases on every tick: timers that are due, then pending I/O callbacks, then poll for new I/O, then setImmediate callbacks, then close callbacks. Between phases it also drains microtasks like resolved Promises and process.nextTick, which run before the loop moves on.
There is a catch. True non-blocking I/O does not exist for everything. File system reads, DNS lookups, and CPU-heavy crypto cannot be done with epoll, so libuv keeps a small background thread pool, four threads by default, and offloads that work there. The single loop thread only handles the network sockets and the orchestration.