Introduction to Microservices with Node.js

Microservices are an architectural style in which a single application is built as a suite of small, independently deployable services, each owning a slice of the business domain and communicating over the network. Instead of one large codebase that must be built, tested, and released as a unit, you assemble many focused services that evolve at their own pace. Node.js — with its lightweight runtime, fast startup, and non-blocking I/O — has become one of the most popular platforms for this style, which is why understanding the architecture matters before you reach for any specific tool.

Monolith vs. microservices

A monolith packages every concern — HTTP routing, business logic, data access, background jobs — into one deployable process. This is simple to start with: one repository, one build, one place to run. The pain appears as the system grows. A change to the billing logic forces a redeploy of the entire application, a memory leak in one feature can crash everything, and teams step on each other in a shared codebase.

A microservices architecture splits that single process into many. Each service has its own codebase, its own database, and its own deployment pipeline. They talk to each other through well-defined contracts — synchronous calls (REST, gRPC) or asynchronous messages (queues, event streams).

Aspect	Monolith	Microservices
Deployment unit	One process	Many independent services
Scaling	Whole app scales together	Scale hot services only
Data	Shared database	One database per service
Failure blast radius	Entire app	Usually one service
Team autonomy	Coordinated releases	Independent releases
Operational complexity	Low	High

Microservices are not a default — they are a trade-off. Many successful products start as a well-structured monolith and extract services only when scaling or team-boundary pressure justifies the added operational cost.

Core characteristics

Three properties separate genuine microservices from a monolith that merely makes a lot of HTTP calls.

Independent deployability. Each service ships on its own schedule without coordinating a big-bang release. This is the single most important benefit — it lets teams move fast without blocking one another.

Bounded contexts. Borrowed from Domain-Driven Design, a bounded context is a clear boundary around a part of the domain (Orders, Payments, Inventory) with its own model and language. A service should map to one bounded context, owning its data exclusively. No other service reaches into its database directly.

Decentralized data. Each service is the sole owner of its persistence. Sharing a database creates hidden coupling — a schema change in one service silently breaks another. The cost is that data consistency across services becomes eventual rather than transactional.

A minimal Node.js service

A microservice is, at its core, just a small program that exposes an interface. Here is a self-contained Orders service using only the built-in HTTP server and native fetch to call a peer.

import { createServer } from 'node:http';

const INVENTORY_URL = process.env.INVENTORY_URL ?? 'http://localhost:3001';

const server = createServer(async (req, res) => {
  res.setHeader('Content-Type', 'application/json');

  if (req.method === 'GET' && req.url === '/health') {
    res.writeHead(200);
    return res.end(JSON.stringify({ status: 'ok' }));
  }

  if (req.method === 'POST' && req.url === '/orders') {
    // Call the inventory service synchronously over the network.
    const response = await fetch(`${INVENTORY_URL}/reserve`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ sku: 'BOOK-001', qty: 1 }),
    });

    if (!response.ok) {
      res.writeHead(409);
      return res.end(JSON.stringify({ error: 'out_of_stock' }));
    }

    res.writeHead(201);
    return res.end(JSON.stringify({ orderId: crypto.randomUUID() }));
  }

  res.writeHead(404);
  res.end(JSON.stringify({ error: 'not_found' }));
});

server.listen(3000, () => console.log('orders service on :3000'));

Output:

orders service on :3000

The service does one thing, owns its endpoint, and reaches the Inventory service only through its public API — never its database. In CommonJS the same file works with const { createServer } = require('node:http').

Why Node.js fits microservices

Node’s design aligns unusually well with the demands of a distributed system.

Lightweight and fast to start. A Node process boots in tens of milliseconds and uses little memory, so running dozens of small services — and scaling them horizontally in containers — is cheap.
Non-blocking I/O. Microservices spend most of their time waiting on the network and databases, not on CPU. Node’s event loop handles thousands of concurrent in-flight requests on a single thread without one slow downstream call blocking the others.
JSON-native. JavaScript objects map directly to JSON, the lingua franca of REST APIs, with zero serialization friction.
Rich ecosystem. npm provides mature clients for every broker and protocol a service mesh needs — Kafka, RabbitMQ, gRPC, Redis, and HTTP frameworks like Express, Fastify, and NestJS.

The same single-threaded model that makes Node great for I/O makes it a poor fit for CPU-heavy services (image processing, ML inference). Offload that work to worker_threads or a separate service in a more suitable runtime.

Trade-offs to weigh

Distribution is not free. Network calls fail, time out, and arrive out of order, so every cross-service interaction needs retries, timeouts, and fallback logic. Debugging spans multiple processes, requiring centralized logging and distributed tracing. Local development now means running many services at once, and data that was a single SQL JOIN in a monolith becomes an orchestration problem across services. Adopt microservices when the organizational and scaling benefits clearly outweigh this operational tax.

Best practices

Start with a modular monolith and extract services along bounded-context seams only when a real need (scaling, team autonomy, fault isolation) appears.
Give every service its own database; never let one service read or write another’s tables directly.
Define explicit, versioned contracts (OpenAPI, Protobuf) so services can evolve without breaking callers.
Treat the network as unreliable: add timeouts, retries with backoff, and circuit breakers to every outbound call.
Make services stateless so they scale horizontally; push session and shared state into Redis or a datastore.
Expose a /health endpoint and emit structured logs with a correlation ID so requests can be traced across services.
Keep services small enough that one team can own, understand, and redeploy a service independently.