Start Here: Do You Actually Need Microservices
Most teams start with a monolith and then, under pressure to scale or reorganize, consider splitting into microservices. The honest answer for most projects is: not yet. Microservices solve specific problems — independent deployment, different scaling requirements per service, multiple teams owning different parts of the system. If you have one team of three developers and a single product, the operational complexity of microservices will slow you down more than it helps.
That said, if you have decided microservices are the right architecture for your situation, here is what actually building them looks like.
Setting Up Individual Services
Each service should be a standalone Node.js process with its own package.json, its own database or data store, and a clear, documented API. Start with Fastify or Express — both work well, though Fastify has better performance characteristics out of the box. The critical discipline is that services must not share databases. If Service A and Service B both query the same PostgreSQL instance and modify the same tables, you have a distributed monolith, which is worse than either a clean monolith or clean microservices.
Use environment variables for all configuration. Service discovery, database credentials, API keys — none of it should be hardcoded. The Node.js process.env API is sufficient, though libraries like convict add schema validation that catches misconfiguration early rather than at runtime.
Communication Patterns
Synchronous HTTP or gRPC between services works for simple cases, but you will hit the cascade failure problem: if Service A calls Service B, and Service B goes down, Service A starts failing too. The solution is to use asynchronous messaging for anything where eventual consistency is acceptable. RabbitMQ, Apache Kafka, or AWS SQS are the common choices. When a user places an order, the order service publishes an event; the inventory service and notification service consume it independently. The services are decoupled, and a failure in one does not bring down the others.
For cases where synchronous calls are genuinely necessary, implement circuit breakers. When Service B starts failing, stop calling it for a period of time rather than waiting for timeouts on every request. The axios-scirent or opossum libraries make this straightforward in Node.js.
The Operational Reality
Three services is manageable. Thirty is a different problem. You now need service discovery so services can find each other without hardcoded hostnames. You need centralized logging so you can trace a request across service boundaries. You need distributed tracing — tools like OpenTelemetry with Jaeger or Zipkin — so you can see where a request slowed down. You need health check endpoints on every service. You need a deployment strategy that handles rolling updates without downtime.
Container orchestration with Kubernetes or managed alternatives like AWS ECS or Google Cloud Run handles much of this. In 2026, the managed options are good enough that you do not need a dedicated platform engineering team to run a reasonable number of microservices. Docker Compose is fine for local development but not production at scale.
The Path That Works
Start with two or three services that have genuinely different concerns — authentication and the main application, for example. Get the operational patterns right before adding more. Use a service mesh like Istio or Linkerd only when you have enough services that traffic management becomes a genuine burden. Add observability before you add complexity. The teams that struggle with microservices are usually the ones that added them all at once without the infrastructure to support them.