fs.readFileSync vs fs.readFile
grasp of blocking vs non-blocking I/O.
sync blocks the event loop and returns directly, async takes a callback or promise, only sync is safe at startup.
using readFileSync inside a request handler.
What's really being asked
This checks if you understand Node's single-threaded event loop and why blocking operations are dangerous in a server. A candidate who treats sync and async as interchangeable does not grasp Node's concurrency model.
The full answer
fs.readFileSync runs synchronously: it blocks the calling thread until the file is fully read, then returns the buffer or throws an error you catch with try/catch. fs.readFile is asynchronous: it returns immediately and delivers the result later through a callback, or through a promise when you use fs.promises.readFile. Because Node serves all requests on one event loop thread, a synchronous read pauses every other pending request and timer for the duration of the disk operation. You choose sync only for one-time setup at process start, such as loading a config file before the server begins listening, where blocking is harmless. You choose async for anything that runs while serving traffic.
The mistakes people make
Saying the only difference is callback style, or that sync is fine because it is simpler. Another mistake is claiming the operating system handles concurrency for you, ignoring that JavaScript execution itself is single-threaded.
What usually comes next
How does the libuv thread pool serve async file I/O. What is the difference between readFile and createReadStream for large files. How do you convert callback APIs to promises with util.promisify.
A concrete example
A server calls fs.readFileSync on a 50MB file inside a route handler. Under load, every incoming request queues behind that read; throughput collapses and latency spikes for all clients. Switching to await fs.promises.readFile lets the event loop keep accepting and dispatching other requests while the disk read proceeds in the background thread pool.
Interview question
Why is calling fs.readFileSync inside an Express request handler a problem under concurrent load?
- a.It spawns a new thread per request, exhausting the thread pool
- b.It silently returns stale cached data from previous reads
- c.It blocks the single event loop thread, stalling all other pending requestsCorrect
- d.It throws an error because sync calls are forbidden in handlers
Why? this is the answer
The sync read blocks the one event loop thread until it finishes, so every other request waits. It is not forbidden and does not spawn threads; the async version uses the libuv pool instead.
Just read this? Test yourself on what you have been reading.
Read the original → nodejs.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on nodejs — each one lists the topics its interview covers.
See open roles