Open ten "Node.js microservices" tutorials and nine start the exact same way: install Express, install an HTTP client, write a docker-compose.yml, stand up a message broker. By the time application code shows up, you've installed six things and still don't know if microservices were even the right call. Node ships with everything two communicating services actually need. node:http is the server. Global fetch is the client. node:test is the runner. --watch is the reloader. No install step, no node_modules. So I built two real services this way: a user service holding user records, and an order service that has to confirm a user exists before creating an order for them, calling across the boundary with a plain fetch. Along the way you run into the actual failure modes of distributed systems, not the theoretical ones. fetch rejects on a refused connection instead of returning a response object, which means an unhandled rejection inside your request handler can take your service down right along with the one it was calling. That single try/catch is the whole lesson. The bigger trap isn't technical though. It's splitting a codebase into two folders while both still connect to the same schema. That gets you all the operational cost of distributed systems and none of the actual benefit, independent deployability included. I walk through building both services, testing them with node:test, and watching the failure happen live (kill one service, watch the other survive, then watch it not survive once you remove the catch) here: https://devencyclopedia.com/blog/nodejs-microservices-without-express If you've been reaching for Express and Docker by default before writing a line of logic, this is worth forty lines of your time first.