Microservices Architecture in Node.js

Your Node.js monolith handles authentication, payments, email, search, and user management. A bug in the email module crashes the entire application, taking payments and search offline with it. Microservices isolate failures, enabling independent deployment, scaling, and technology choices for each service. But microservices also introduce complexity: network latency, data consistency, service discovery, and distributed debugging. This article covers when microservices make sense, how to split a Node.js monolith, inter-service communication patterns, and the production infrastructure you need before migrating.

Why Microservices in Node.js?

Monoliths work until they don't. When your Node.js application grows beyond a few dozen endpoints, deployment coupling, scaling inefficiencies, and team coordination bottlenecks emerge. Microservices decompose the monolith into independently deployable services, each owning a bounded context. Node.js is a strong fit due to its non-blocking I/O, lightweight process model, and rich ecosystem for HTTP and message-based communication. However, microservices introduce distributed system complexity: network latency, partial failures, data consistency, and observability overhead. The decision to adopt microservices should be driven by organizational scalability and deployment autonomy, not by hype. Start with a modular monolith and extract services only when the pain justifies the cost.

// Monolith: single Express app
const express = require('express');
const app = express();
app.use('/users', require('./routes/users'));
app.use('/orders', require('./routes/orders'));
app.listen(3000);

// Microservice: separate process for users
const express = require('express');
const app = express();
app.get('/users/:id', async (req, res) => {
  const user = await db.findUser(req.params.id);
  res.json(user);
});
app.listen(3001);

Service Boundaries and Domain-Driven Design

The hardest part of microservices is defining service boundaries. Domain-Driven Design (DDD) provides tactical patterns: bounded contexts, aggregates, and domain events. Each microservice should own a bounded context — a cohesive subdomain with its own data model and logic. For example, an e-commerce system might have separate services for Catalog, Cart, Orders, and Payments. The key is to minimize cross-service communication: if two contexts frequently need synchronous calls, they might belong together. Use event-driven communication for eventual consistency across contexts. Define aggregates as consistency boundaries within a service; never span aggregates across services. A common mistake is splitting by technical layers (e.g., a 'data service' or 'logic service') — this creates chatty, fragile systems.

// Order service - owns order data and logic
class OrderService {
  async createOrder(userId, items) {
    const order = new Order({ userId, items, status: 'pending' });
    await this.orderRepo.save(order);
    await this.eventBus.publish('order.created', { orderId: order.id });
    return order;
  }
}

// Payment service - subscribes to order.created
class PaymentService {
  constructor() {
    this.eventBus.subscribe('order.created', async (event) => {
      await this.processPayment(event.orderId);
    });
  }
}

Inter-Service Communication: REST, gRPC, and Message Queues

Services need to talk. The three main patterns are synchronous (REST, gRPC) and asynchronous (message queues, event streams). REST is simple and ubiquitous but suffers from chatty interfaces and tight coupling. gRPC offers typed contracts, streaming, and better performance via HTTP/2 and protobuf — ideal for internal high-throughput calls. Message queues (RabbitMQ, Kafka) decouple services and enable event-driven architectures. Choose synchronous calls for queries that need immediate consistency (e.g., 'get user profile'). Use async for commands that can tolerate eventual consistency (e.g., 'place order'). Always implement circuit breakers and retries with exponential backoff for synchronous calls. Prefer idempotent consumers for async to handle duplicate messages.

// gRPC service definition (user.proto)
service UserService {
  rpc GetUser (GetUserRequest) returns (User);
}
message GetUserRequest { string id = 1; }
message User { string id = 1; string name = 2; }

// Node.js server
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
const packageDef = protoLoader.loadSync('user.proto');
const grpcObj = grpc.loadPackageDefinition(packageDef);
const server = new grpc.Server();
server.addService(grpcObj.UserService.service, {
  GetUser: (call, callback) => {
    const user = { id: call.request.id, name: 'Alice' };
    callback(null, user);
  }
});
server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => {
  server.start();
});

API Gateway Pattern

An API gateway acts as a single entry point for clients, routing requests to appropriate microservices. It handles cross-cutting concerns: authentication, rate limiting, logging, and response aggregation. In Node.js, popular gateways include Express-based custom gateways, Kong, or Envoy. The gateway should not contain business logic — it's a proxy. For mobile clients, the gateway can compose responses from multiple services (e.g., fetch user + orders in one call). However, avoid turning the gateway into a monolithic orchestrator; use backend-for-frontend (BFF) patterns if needed. Always implement health checks and graceful degradation. A common pitfall is making the gateway too smart, leading to tight coupling and a single point of failure.

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();

app.use('/users', createProxyMiddleware({ target: 'http://user-service:3001', changeOrigin: true }));
app.use('/orders', createProxyMiddleware({ target: 'http://order-service:3002', changeOrigin: true }));

app.get('/health', (req, res) => res.json({ status: 'UP' }));

app.listen(3000);

Service Discovery and Load Balancing

In a dynamic microservices environment, service instances come and go. Service discovery allows services to find each other without hardcoded addresses. Two patterns: client-side discovery (service registry like Consul, etcd) and server-side discovery (load balancer like Nginx, HAProxy). For Node.js, client-side discovery with Consul is common: each service registers itself on startup and deregisters on shutdown. The client queries the registry to get healthy instances and load balances (e.g., round-robin). Kubernetes provides built-in service discovery via DNS and endpoints. In production, always use health checks to remove unhealthy instances. A common failure is stale registry entries causing requests to dead instances — implement TTL and heartbeats.

const consul = require('consul')();
const express = require('express');
const app = express();

const serviceId = 'user-service-1';
app.get('/health', (req, res) => res.json({ status: 'pass' }));

app.listen(3001, () => {
  consul.agent.service.register({
    id: serviceId,
    name: 'user-service',
    address: 'localhost',
    port: 3001,
    check: { http: 'http://localhost:3001/health', interval: '10s' }
  }, (err) => {
    if (err) console.error('Registration failed', err);
  });
});

process.on('SIGINT', () => {
  consul.agent.service.deregister(serviceId, () => process.exit());
});

Data Management: Database per Service and Eventual Consistency

Each microservice should own its database — no shared databases. This ensures loose coupling and independent deployability. However, it introduces data consistency challenges. For transactions spanning services, use the Saga pattern: a sequence of local transactions with compensating actions on failure. Sagas can be choreographed (each service publishes events) or orchestrated (a coordinator service). For queries that need data from multiple services, use Command Query Responsibility Segregation (CQRS) with materialized views. In Node.js, implement sagas using message queues and idempotent handlers. Avoid distributed transactions (2PC) — they are slow and fragile. Accept eventual consistency as a trade-off for scalability.

// Order service
class OrderSaga {
  async createOrder(userId, items) {
    const order = await this.orderRepo.save({ userId, items, status: 'pending' });
    await this.eventBus.publish('order.created', { orderId: order.id, userId });
  }
}

// Inventory service
class InventorySaga {
  constructor() {
    this.eventBus.subscribe('order.created', async (event) => {
      try {
        await this.reserveInventory(event.orderId);
        await this.eventBus.publish('inventory.reserved', event);
      } catch (err) {
        await this.eventBus.publish('inventory.failed', event);
      }
    });
    this.eventBus.subscribe('payment.failed', async (event) => {
      await this.releaseInventory(event.orderId);
    });
  }
}

Observability: Logging, Metrics, and Tracing

Microservices are distributed, making debugging hard. Observability is the ability to understand system state from external outputs. Three pillars: logging (structured, centralized), metrics (latency, error rates, throughput), and distributed tracing (trace requests across services). Use structured logging (JSON) with correlation IDs to trace requests. For metrics, use Prometheus with Node.js client libraries. For tracing, implement OpenTelemetry to propagate trace context via HTTP headers. In production, aggregate logs in Elasticsearch, metrics in Grafana, and traces in Jaeger. A common failure is inconsistent correlation IDs — always pass them via middleware. Without tracing, debugging a slow request across 10 services is nearly impossible.

const { trace, context } = require('@opentelemetry/api');
const express = require('express');
const app = express();

app.use((req, res, next) => {
  const tracer = trace.getTracer('my-service');
  const span = tracer.startSpan('http.request');
  context.with(trace.setSpan(context.active(), span), () => {
    res.on('finish', () => {
      span.setAttribute('http.status_code', res.statusCode);
      span.end();
    });
    next();
  });
});

app.get('/api', (req, res) => {
  res.json({ message: 'Hello' });
});

app.listen(3000);

Testing Microservices: Integration and Contract Tests

Testing microservices requires a shift from monolithic integration tests. Unit tests remain important, but the critical tests are integration tests (service-level) and contract tests (between services). Integration tests should test each service in isolation with its real database (use testcontainers for Postgres, etc.). Contract tests (e.g., Pact) verify that service A's expectations of service B's API are met — they catch breaking changes early. Avoid end-to-end tests that spin up all services — they are slow and flaky. Instead, use consumer-driven contracts to ensure compatibility. In Node.js, use supertest for HTTP integration tests and @pact-foundation/pact for contract tests. Always run contract tests in CI to prevent incompatible deployments.

const { Pact } = require('@pact-foundation/pact');
const { API } = require('./api');

const provider = new Pact({
  consumer: 'OrderService',
  provider: 'UserService',
  port: 1234,
});

beforeAll(() => provider.setup());
afterAll(() => provider.finalize());

describe('User Service contract', () => {
  test('should return user by ID', async () => {
    await provider.addInteraction({
      state: 'user exists',
      uponReceiving: 'a request for user',
      withRequest: { method: 'GET', path: '/users/1' },
      willRespondWith: { status: 200, body: { id: '1', name: 'Alice' } },
    });
    const api = new API(provider.mockService.baseUrl);
    const user = await api.getUser('1');
    expect(user).toEqual({ id: '1', name: 'Alice' });
  });
});

Deployment and CI/CD for Microservices

Each microservice should have its own CI/CD pipeline, build artifact, and deployment strategy. Use containerization (Docker) for consistent environments. Orchestrate with Kubernetes or a simpler platform like Nomad. Implement blue-green or canary deployments to reduce risk. In CI, run unit tests, contract tests, and security scans. Build a Docker image and push to a registry. In CD, deploy to a staging environment, run smoke tests, then promote to production. Use feature flags to decouple deployment from release. A common pitfall is a monolithic CI pipeline that builds all services together — this defeats the purpose of microservices. Each service should be deployable independently.

name: Deploy User Service
on:
  push:
    branches: [main]
    paths: ['services/user/**']
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build Docker image
        run: docker build -t user-service:latest ./services/user
      - name: Push to registry
        run: docker push registry.example.com/user-service:latest
      - name: Deploy to Kubernetes
        run: kubectl set image deployment/user-service user-service=registry.example.com/user-service:latest

Common Pitfalls and Anti-Patterns

Microservices introduce complexity. Common anti-patterns include: distributed monolith (services tightly coupled via synchronous calls), shared database, anemic services (CRUD without logic), chatty communication (too many small requests), and ignoring data consistency. Another pitfall is over-engineering: starting with microservices for a small team is a mistake. Also, avoid rolling your own service mesh or API gateway — use battle-tested solutions like Envoy or Kong. In Node.js, watch out for memory leaks in long-running processes and ensure graceful shutdown. Finally, don't neglect observability until after an incident — invest early.

// Anti-pattern: chatty synchronous calls
async function getOrderDetails(orderId) {
  const order = await http.get(`http://order-service/orders/${orderId}`);
  const user = await http.get(`http://user-service/users/${order.userId}`);
  const product = await http.get(`http://catalog-service/products/${order.productId}`);
  return { ...order, user, product };
}

// Better: aggregate in a BFF or use GraphQL federation
async function getOrderDetails(orderId) {
  const response = await http.get(`http://bff/orders/${orderId}?include=user,product`);
  return response.data;
}

When to Avoid Microservices

Microservices are not a silver bullet. Avoid them if your team is small (<10 developers), your domain is simple, or you have no deployment automation. Start with a modular monolith — structure your code into well-defined modules with clear interfaces. You can extract services later when the need arises. Also, avoid microservices if your organization cannot support the operational overhead: multiple databases, CI/CD pipelines, monitoring, and incident response. For many startups, a monolith with a clear internal architecture is faster to build and iterate. Remember: the goal is to deliver value, not to use a trendy architecture.

// Modular monolith: separate modules with clear boundaries
const express = require('express');
const app = express();

// User module
const userModule = require('./modules/user');
app.use('/users', userModule.router);

// Order module
const orderModule = require('./modules/order');
app.use('/orders', orderModule.router);

// Each module has its own database connection and models
app.listen(3000);

Conclusion: Build for the Right Reasons

Microservices in Node.js can enable independent deployment, team autonomy, and scalability — but at the cost of operational complexity. The key is to start with a modular monolith, extract services when the pain of coupling exceeds the pain of distribution, and invest heavily in observability, CI/CD, and testing. Remember that the architecture should serve the business, not the other way around. As a senior developer, your job is to make pragmatic trade-offs. Use the patterns in this article to build resilient, maintainable systems — but always question whether the complexity is justified.

Is your team > 10 developers? -> Yes -> Do you have independent deployability needs? -> Yes -> Consider microservices
Is your domain complex with clear bounded contexts? -> Yes -> Consider microservices
Otherwise -> Start with modular monolith

Saga Pattern Implementation

Distributed transactions across microservices require careful handling. The Saga pattern manages failures by breaking a transaction into a sequence of local transactions, each with a compensating action. Two approaches exist: choreography (each service publishes events) and orchestration (a coordinator directs steps). For Node.js, orchestration with a dedicated saga orchestrator service is recommended for complex workflows. Use a message broker like RabbitMQ or Kafka to emit events. Implement idempotency keys and retry logic to handle duplicates. Example: an order saga might reserve inventory, charge payment, and confirm shipment. If payment fails, compensate by releasing inventory. Use libraries like 'sagas' or build your own with state machines. Always log saga state transitions for debugging.

const { v4: uuidv4 } = require('uuid');
const amqp = require('amqplib');

class SagaOrchestrator {
  constructor() {
    this.sagas = new Map();
  }

  async startSaga(orderId) {
    const sagaId = uuidv4();
    const saga = { id: sagaId, orderId, step: 0, state: 'PENDING' };
    this.sagas.set(sagaId, saga);
    await this.executeStep(saga);
    return sagaId;
  }

  async executeStep(saga) {
    const steps = [
      { service: 'inventory', action: 'reserve', compensate: 'release' },
      { service: 'payment', action: 'charge', compensate: 'refund' },
      { service: 'shipping', action: 'ship', compensate: 'cancelShipment' }
    ];
    const step = steps[saga.step];
    try {
      await this.callService(step.service, step.action, saga.orderId);
      saga.step++;
      if (saga.step >= steps.length) {
        saga.state = 'COMPLETED';
        console.log(`Saga ${saga.id} completed`);
      } else {
        await this.executeStep(saga);
      }
    } catch (err) {
      saga.state = 'FAILED';
      console.error(`Saga ${saga.id} failed at step ${saga.step}: ${err.message}`);
      await this.compensate(saga, steps);
    }
  }

  async compensate(saga, steps) {
    for (let i = saga.step - 1; i >= 0; i--) {
      const step = steps[i];
      await this.callService(step.service, step.compensate, saga.orderId);
    }
    saga.state = 'COMPENSATED';
  }

  async callService(service, action, orderId) {
    // Publish message to service queue
    const conn = await amqp.connect('amqp://localhost');
    const ch = await conn.createChannel();
    await ch.assertQueue(service);
    ch.sendToQueue(service, Buffer.from(JSON.stringify({ action, orderId })));
    // In production, wait for reply with timeout
  }
}

module.exports = SagaOrchestrator;

CQRS and Event Sourcing

CQRS (Command Query Responsibility Segregation) separates write and read models, optimizing each for its workload. Event sourcing stores state changes as an append-only event log. Combined, they enable powerful audit trails and temporal queries. In Node.js, implement commands that validate and emit events, and projections that build read models from events. Use a message broker to distribute events. Example: an order service writes events (OrderCreated, OrderShipped) to an event store (e.g., EventStoreDB or PostgreSQL). A separate read service subscribes to events and updates a denormalized view for fast queries. This pattern adds complexity but excels in high-write or audit-heavy systems. Avoid CQRS/ES for simple CRUD; it's overkill.

const { Client } = require('pg');
const amqp = require('amqplib');

class EventStore {
  constructor() {
    this.client = new Client({ connectionString: process.env.DATABASE_URL });
  }

  async appendEvent(aggregateId, event) {
    await this.client.query(
      'INSERT INTO events (aggregate_id, event_type, data, version) VALUES ($1, $2, $3, $4)',
      [aggregateId, event.type, JSON.stringify(event.data), event.version]
    );
    // Publish to message broker
    const conn = await amqp.connect('amqp://localhost');
    const ch = await conn.createChannel();
    await ch.assertExchange('events', 'topic', { durable: true });
    ch.publish('events', event.type, Buffer.from(JSON.stringify(event)));
  }

  async getEvents(aggregateId) {
    const res = await this.client.query(
      'SELECT * FROM events WHERE aggregate_id = $1 ORDER BY version',
      [aggregateId]
    );
    return res.rows;
  }
}

// Projection example
class OrderProjection {
  constructor() {
    this.orders = new Map();
  }

  applyEvent(event) {
    if (event.type === 'OrderCreated') {
      this.orders.set(event.data.orderId, { status: 'created', items: event.data.items });
    } else if (event.type === 'OrderShipped') {
      const order = this.orders.get(event.data.orderId);
      if (order) order.status = 'shipped';
    }
  }
}

module.exports = { EventStore, OrderProjection };

Circuit Breaker Pattern

Circuit breakers prevent cascading failures by stopping calls to a failing service. When failures exceed a threshold, the circuit opens and subsequent calls fail fast. After a timeout, a half-open state allows a probe request; if it succeeds, the circuit closes. In Node.js, use libraries like 'opossum' or 'cockatiel'. Configure thresholds: failure count, timeout, and reset timeout. Example: an API gateway calls a payment service with a circuit breaker. If payment service returns 5xx errors 3 times in 10 seconds, the circuit opens for 30 seconds. During open, return a cached response or fallback. Always log circuit state changes. Combine with retry/backoff for transient failures.

const CircuitBreaker = require('opossum');
const axios = require('axios');

async function callPaymentService(orderId) {
  const response = await axios.post('http://payment-service/charge', { orderId });
  return response.data;
}

const options = {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000,
  name: 'payment-service'
};

const breaker = new CircuitBreaker(callPaymentService, options);

breaker.fallback(() => ({ status: 'fallback', message: 'Payment service unavailable, order queued' }));

breaker.on('open', () => console.log('Circuit opened for payment-service'));
breaker.on('halfOpen', () => console.log('Circuit half-open for payment-service'));
breaker.on('close', () => console.log('Circuit closed for payment-service'));

// Usage
async function processOrder(orderId) {
  try {
    const result = await breaker.fire(orderId);
    console.log('Payment result:', result);
  } catch (err) {
    console.error('Payment failed:', err.message);
  }
}

module.exports = { processOrder, breaker };

Message Broker Deep Dive: Kafka vs RabbitMQ

Choosing the right message broker is critical for inter-service communication. RabbitMQ is a general-purpose broker with AMQP, supporting complex routing and direct messaging. Kafka is a distributed streaming platform optimized for high throughput, replayability, and event sourcing. Use RabbitMQ for task queues, RPC, and low-latency messaging. Use Kafka for event streaming, log aggregation, and large-scale data pipelines. In Node.js, 'amqplib' for RabbitMQ and 'kafkajs' for Kafka. Consider: RabbitMQ has built-in retry/dead-letter queues; Kafka requires consumer-side handling. Kafka persists messages longer, enabling replay. Both support clustering. For microservices, start with RabbitMQ; move to Kafka when you need replay or high throughput.

// RabbitMQ producer
const amqp = require('amqplib');
async function rabbitSend(queue, msg) {
  const conn = await amqp.connect('amqp://localhost');
  const ch = await conn.createChannel();
  await ch.assertQueue(queue, { durable: true });
  ch.sendToQueue(queue, Buffer.from(msg), { persistent: true });
  setTimeout(() => conn.close(), 500);
}

// Kafka producer
const { Kafka } = require('kafkajs');
const kafka = new Kafka({ clientId: 'my-app', brokers: ['localhost:9092'] });
const producer = kafka.producer();
async function kafkaSend(topic, msg) {
  await producer.connect();
  await producer.send({ topic, messages: [{ value: msg }] });
  await producer.disconnect();
}

// RabbitMQ consumer
async function rabbitConsume(queue, handler) {
  const conn = await amqp.connect('amqp://localhost');
  const ch = await conn.createChannel();
  await ch.assertQueue(queue, { durable: true });
  ch.consume(queue, msg => {
    handler(msg.content.toString());
    ch.ack(msg);
  });
}

// Kafka consumer
const consumer = kafka.consumer({ groupId: 'test-group' });
async function kafkaConsume(topic, handler) {
  await consumer.connect();
  await consumer.subscribe({ topic, fromBeginning: true });
  await consumer.run({ eachMessage: async ({ message }) => handler(message.value.toString()) });
}

Canary and Blue-Green Deployments

Deploying microservices with zero downtime requires advanced strategies. Blue-green deployments run two identical environments (blue and green). Traffic is switched all at once. Canary deployments gradually shift a percentage of traffic to the new version, monitoring for errors. Use a service mesh (e.g., Istio) or API gateway (e.g., Kong) to control traffic splitting. In Node.js, implement canary via Kubernetes with multiple deployments and a service selector. Example: deploy v2 with 10% traffic, monitor for 5 minutes, then increase to 50%, then 100%. Automate rollback if error rate spikes. Blue-green is simpler; canary is safer for high-risk changes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-service
      version: canary
  template:
    metadata:
      labels:
        app: my-service
        version: canary
    spec:
      containers:
      - name: my-service
        image: my-service:2.0.0
        ports:
        - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-service
  ports:
  - port: 80
    targetPort: 3000

OpenTelemetry Distributed Tracing

Distributed tracing correlates requests across microservices. OpenTelemetry is the standard for collecting traces, metrics, and logs. Instrument Node.js services with the OpenTelemetry SDK. Export traces to Jaeger or Zipkin. Use context propagation via HTTP headers (W3C Trace-Context). Example: an API gateway receives a request, creates a span, and injects trace context into downstream calls. Each service creates child spans. Traces show latency breakdown and error sources. In production, sample traces (e.g., 10%) to reduce overhead. Use automatic instrumentation for Express, gRPC, and database clients.

const { NodeTracerProvider } = require('@opentelemetry/sdk-trace-node');
const { SimpleSpanProcessor } = require('@opentelemetry/sdk-trace-base');
const { JaegerExporter } = require('@opentelemetry/exporter-jaeger');
const { ExpressInstrumentation } = require('@opentelemetry/instrumentation-express');
const { HttpInstrumentation } = require('@opentelemetry/instrumentation-http');
const { registerInstrumentations } = require('@opentelemetry/instrumentation');

const provider = new NodeTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(new JaegerExporter({
  endpoint: 'http://jaeger:14268/api/traces',
})));
provider.register();

registerInstrumentations({
  instrumentations: [
    new ExpressInstrumentation(),
    new HttpInstrumentation(),
  ],
});

const express = require('express');
const app = express();

app.get('/api/orders', async (req, res) => {
  // Automatic tracing captures this request
  const response = await fetch('http://order-service/orders');
  const data = await response.json();
  res.json(data);
});

app.listen(3000);

Bulkhead Pattern in Node.js Microservices

The bulkhead pattern isolates resources to prevent cascading failures. In Node.js, implement bulkheads using connection pools, thread pools, or process isolation. For example, separate database connection pools for different services or use worker threads for CPU-intensive tasks. A common approach is to use the generic-pool library to create pools with max limits. When one pool exhausts, it fails fast without starving others. In microservices, apply bulkheads at the service level: run critical and non-critical services in separate processes or containers with dedicated resources. This ensures that a memory leak in a logging service doesn't crash the payment service. Production insight: monitor pool utilization and set alerts when pools reach 80% capacity to proactively scale.

const genericPool = require('generic-pool');
const { Pool } = require('pg');

const factory = {
  create: () => new Pool({ max: 10, idleTimeoutMillis: 30000 }),
  destroy: (pool) => pool.end()
};

const pool = genericPool.createPool(factory, {
  max: 5, // max pools
  min: 2
});

async function query(sql) {
  const client = await pool.acquire();
  try {
    return await client.query(sql);
  } finally {
    pool.release(client);
  }
}

Retry and Backoff Strategies for Resilient Communication

Transient failures are inevitable in distributed systems. Implement retry with exponential backoff and jitter to avoid thundering herd. In Node.js, use libraries like async-retry or p-retry. Configure max retries (3-5), initial delay (100ms), and factor (2). Add jitter by randomizing delay up to 50% to spread retries. For idempotent operations (e.g., GET, PUT with idempotency keys), retry safely. For non-idempotent, use a saga or compensate. Production insight: monitor retry rates; high retry counts indicate underlying issues. Use circuit breakers to stop retrying when service is down. Example: retry with exponential backoff for a database call.

const retry = require('async-retry');
const axios = require('axios');

async function fetchWithRetry(url) {
  return retry(async (bail) => {
    const response = await axios.get(url);
    if (response.status === 429) {
      throw new Error('Rate limited'); // retry
    }
    return response.data;
  }, {
    retries: 3,
    minTimeout: 100,
    maxTimeout: 1000,
    factor: 2,
    onRetry: (error, attempt) => {
      console.log(`Retry ${attempt}: ${error.message}`);
    }
  });
}

Health Check API Standards for Node.js Microservices

Health checks are essential for orchestration and load balancers. Follow the RFC 9560 (Health Check Response Format) standard: expose a /healthz endpoint returning JSON with status (pass, warn, fail), version, and dependencies. Use readiness and liveness probes: readiness indicates service is ready to accept traffic (e.g., DB connected), liveness indicates service is alive (e.g., process not stuck). In Node.js, implement using a library like health-checkup or custom middleware. Example: a health check that pings database and cache. Production insight: include critical dependency status but avoid deep checks that could cause cascading failures. Set timeouts and cache results for 5-10 seconds.

const express = require('express');
const app = express();

app.get('/healthz', async (req, res) => {
  const checks = {
    status: 'pass',
    version: '1.0.0',
    checks: {}
  };

  try {
    await db.ping();
    checks.checks.database = { status: 'pass' };
  } catch (err) {
    checks.checks.database = { status: 'fail', message: err.message };
    checks.status = 'fail';
  }

  try {
    await cache.ping();
    checks.checks.cache = { status: 'pass' };
  } catch (err) {
    checks.checks.cache = { status: 'fail', message: err.message };
    checks.status = 'fail';
  }

  res.status(checks.status === 'pass' ? 200 : 503).json(checks);
});