Introduction to Microservices

Microservices is an architectural style where a system is built as a collection of small, independently deployable services — each owning a single business capability, running its own process, and communicating over a network. It's the opposite of a monolith, where all features share one codebase and process. Microservices promise independent scaling, independent deployment, and technology freedom per service; they impose distributed-systems complexity: network calls, eventual consistency, service discovery, and operational overhead that a monolith sidesteps entirely. This page explains the model, its genuine benefits, its real costs, and when Node teams should actually reach for it.

The core idea

Text

MONOLITH                               MICROSERVICES
┌──────────────────────────┐            ┌──────────┐  ┌──────────┐  ┌──────────┐
│ users     orders  billing │            │  Users   │  │  Orders  │  │ Billing  │
│ products  search  emails  │            │ Service  │  │ Service  │  │ Service  │
│                           │            └────┬─────┘  └────┬─────┘  └────┬─────┘
│    one process            │                 └─────────────┴─────────────┘
│    one database           │                       network calls
└──────────────────────────┘            each has its OWN database, deploy cycle

Each microservice owns one capability, one database, and deploys independently — the network is the boundary between them

A microservice is defined by three properties: a **single business capability** (users, orders, billing — not "all the business logic"), a **private data store** (the service owns its schema, nothing reads its DB directly), and **independent deployability** (you ship the orders service without touching billing or users). The network replaces in-process function calls: services communicate via HTTP/REST, [gRPC](/nodejs/grpc), or [message queues](/nodejs/message-queues). The key benefit is that organizational autonomy follows technical autonomy — a team that owns the orders service can release, scale, and rewrite it on their own schedule. The key cost is that every cross-service interaction is now a fallible network call: you inherit latency, partial failures, retry logic, and eventual consistency wherever a monolith would have had a function call.

Genuine benefits

Independent deployment — ship the orders service on Tuesday and billing on Thursday without coordinating or risking the whole app.
Independent scaling — scale the search service to 100 instances without scaling the unrelated user-settings service.
Technology freedom — a computationally intensive service can be Go; a data-science service can be Python; the user-facing API can be Node.
Fault isolation — a buggy billing service crashes in isolation; orders and users keep serving (with proper bulkheads and timeouts).
Team autonomy — small teams own small services end to end, avoiding coordination overhead that grows quadratically in a monolith.

Real costs

Microservices replace in-process complexity with distributed-system complexity — don't adopt them before you feel the monolith's pain

The list of problems microservices introduce is long and serious. **Network calls** fail, are slow, and add latency where a monolith has a nanosecond function call. **Distributed transactions** (update orders *and* billing atomically) are fundamentally hard — you use sagas, outbox patterns, or eventual consistency, all of which add code and failure modes. **Debugging** is harder — a request spans five services and five log streams; you need distributed tracing to understand it. **Operational overhead** multiplies: each service needs its own [CI/CD](/nodejs/ci-cd), [monitoring](/nodejs/monitoring-apm), [Docker image](/nodejs/docker), and deployment pipeline. Service discovery, API gateways, load balancing, and health checks must all be managed at the system level. **Testing** is harder — integration tests must spin up multiple services. Start with these costs and ask whether your current pain (slow deploys? scaling bottlenecks? team coordination?) justifies paying them. Most teams don't need microservices yet.

Node and microservices — a natural fit, with caveats

Node strength in microservices	Watch out for
Fast startup — ideal for containers that scale to zero	CPU-heavy services belong in Go/Rust, not Node
Async I/O — efficient for service-to-service HTTP calls and event consumers	Single-threaded; blocking one consumer blocks all
Small, focused services match Node's lightweight module model	Shared libraries across services create coupling without visibility
TypeScript shared types across services (in a monorepo)	Cross-service type sharing can recreate tight coupling

Node is well-suited for the I/O-heavy coordination role microservices often play — but use the right tool per service

Node's **fast startup**, **low memory footprint**, and **async I/O** make it a natural fit for microservices, particularly for services that coordinate other services (API gateways, BFF layers) or consume event streams. Services that are primarily I/O-bound — receiving requests, calling a database, calling other services — map well to Node's strengths. Where Node is less suited is in **CPU-intensive services** (image processing, ML inference, heavy data transformation) — those often belong in Go, Rust, or Python regardless of what the rest of the system uses. One of microservices' technical freedoms is the ability to make this choice per service; use it deliberately.

Before choosing, understand the full trade-off: [Monolith vs Microservices](/nodejs/monolith-vs-microservices).