Building Scalable Microservices with Node.js and Kubernetes

Modern distributed systems demand architectures that can scale independently, fail gracefully, and deploy without downtime. In this post, I'll walk through the patterns and practices I use to build production-grade microservices.

Why Microservices?

Monolithic applications work great until they don't. When your team grows, your codebase becomes a bottleneck. Microservices let you:

• Scale independently — only scale the services that need it
• Deploy independently — ship features without coordinating releases
• Choose the right tool — use different languages or databases per service
• Isolate failures — one service going down doesn't take everything with it

The Architecture

Here's the high-level architecture I typically use:

                    ┌─────────────┐
                    │   API GW    │
                    └──────┬──────┘
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │ Auth Svc  │ │ User Svc │ │Order Svc │
        └──────────┘ └──────────┘ └──────────┘
              │            │            │
              ▼            ▼            ▼
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │  Redis   │ │ Postgres │ │ MongoDB  │
        └──────────┘ └──────────┘ └──────────┘

Each service owns its data, communicates via events through a message broker, and exposes a well-defined API contract.

Service Design Principles

1. Single Responsibility

Each microservice should do one thing well. If you find yourself adding unrelated features, it's time to split.

// Good: Auth service only handles authentication
class AuthService {
  async login(credentials: Credentials): Promise<Token> { /* ... */ }
  async verify(token: string): Promise<User> { /* ... */ }
  async refresh(token: string): Promise<Token> { /* ... */ }
}

2. API-First Design

Define your API contract before writing implementation. I use OpenAPI specs to ensure consistency:

openapi: 3.0.0
paths:
  /api/users/{id}:
    get:
      summary: Get user by ID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: User found

3. Circuit Breaker Pattern

When a downstream service is unhealthy, stop sending requests to it. This prevents cascading failures:

import CircuitBreaker from 'opossum';

const breaker = new CircuitBreaker(callExternalService, {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000,
});

breaker.fallback(() => cachedResponse);

Kubernetes Deployment

Kubernetes provides the orchestration layer that makes microservices manageable in production.

Health Checks

Every service needs liveness and readiness probes:

livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 10
  periodSeconds: 15
readinessProbe:
  httpGet:
    path: /ready
    port: 3000
  initialDelaySeconds: 5
  periodSeconds: 10

Horizontal Pod Autoscaling

Scale based on actual demand:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Observability

You can't manage what you can't measure. Every service should emit:

• Structured logs — JSON format with correlation IDs
• Metrics — request rate, error rate, latency (RED method)
• Traces — distributed tracing with OpenTelemetry

Key Takeaways

1. Start with a modular monolith, extract services when the boundary is clear
2. Invest in observability from day one
3. Use async communication (events) over sync (HTTP) where possible
4. Automate everything — CI/CD, infrastructure, scaling
5. Design for failure — everything will break eventually

Microservices aren't a silver bullet, but when applied thoughtfully, they unlock the ability to build systems that scale with your team and your traffic.