Microservices Architecture: Design Patterns and Best Practices

Here's the uncomfortable truth about microservices security: every service boundary is a potential security vulnerability. In a monolith, you have one perimeter to defend. With microservices, you have dozens or hundreds. Each service-to-service call is a network request that can be intercepted, each service needs authentication and authorization, and a compromised service can become a foothold for attackers to pivot through your entire system.

I've audited microservices architectures where internal services trusted each other completely with no authentication. One compromised container gave attackers access to everything. Another company had services communicating over unencrypted HTTP within their "secure" private network - until an insider threat exploited it. These aren't theoretical risks; they're real breaches that cost millions.

The attack surface explosion is real. A monolith might have 5 external APIs to secure. The same application split into 20 microservices now has 20 services × 19 potential service-to-service calls = 380 communication paths to secure. Each one needs encryption, authentication, authorization, rate limiting, and monitoring. Miss one, and you have a security hole.

Zero Trust Architecture: Never Trust, Always Verify

The old "trust the internal network" model doesn't work with microservices. You need zero trust: assume every request is potentially malicious, even if it comes from inside your network. Every service must authenticate and authorize every request, no exceptions.

// Service-to-service authentication with JWT
const jwt = require('jsonwebtoken');

// Each service has its own service account token
const SERVICE_TOKEN = process.env.SERVICE_TOKEN;
const SERVICE_SECRET = process.env.JWT_SECRET;

// Middleware to verify calling service
function authenticateService(req, res, next) {
  const token = req.headers['x-service-token'];

  if (!token) {
    return res.status(401).json({
      error: 'Service authentication required'
    });
  }

  try {
    const decoded = jwt.verify(token, SERVICE_SECRET);

    // Verify the service is allowed to call this endpoint
    if (!isAuthorized(decoded.service, req.path)) {
      return res.status(403).json({
        error: 'Service not authorized for this operation'
      });
    }

    req.callingService = decoded.service;
    next();
  } catch (error) {
    return res.status(401).json({
      error: 'Invalid service token'
    });
  }
}

// Service makes authenticated call to another service
async function callUserService(userId) {
  const response = await fetch(`http://user-service/api/users/${userId}`, {
    headers: {
      'X-Service-Token': SERVICE_TOKEN,
      'Content-Type': 'application/json'
    }
  });

  if (!response.ok) {
    throw new Error('Service call failed');
  }

  return response.json();
}

Service Mesh: Security at the Infrastructure Layer

Service meshes like Istio and Linkerd handle security concerns at the infrastructure level, so you don't have to implement them in every service. They provide automatic mTLS encryption, authentication, authorization policies, and traffic management. This is the industry standard for securing large microservices deployments.

# Istio Authorization Policy Example
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: order-service-authz
  namespace: production
spec:
  selector:
    matchLabels:
      app: order-service
  action: ALLOW
  rules:
  # Only API gateway can call order service
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/api-gateway"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/orders/*"]

  # User service can only call specific endpoints
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/user-service"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/api/orders/user/*"]

# This is enforced at the network level by Istio
# Services don't need to implement authorization logic

Rate Limiting and Circuit Breaking

Distributed systems are vulnerable to cascading failures. One slow service can bring down your entire system. Rate limiting prevents services from overwhelming each other, and circuit breakers stop the cascade before it starts.

// Circuit breaker pattern with retry logic
const CircuitBreaker = require('opossum');

// Configure circuit breaker
const options = {
  timeout: 3000, // 3 second timeout
  errorThresholdPercentage: 50, // Open after 50% failures
  resetTimeout: 30000 // Try again after 30 seconds
};

// Wrap service call in circuit breaker
const callOrderService = new CircuitBreaker(async (orderId) => {
  const response = await fetch(`http://order-service/api/orders/${orderId}`);
  if (!response.ok) throw new Error('Service error');
  return response.json();
}, options);

// Handle circuit breaker states
callOrderService.on('open', () => {
  console.error('Circuit breaker opened - service is failing');
  // Alert operations team
});

callOrderService.on('halfOpen', () => {
  console.log('Circuit breaker testing service recovery');
});

// Use with fallback
async function getOrder(orderId) {
  try {
    return await callOrderService.fire(orderId);
  } catch (error) {
    // Circuit is open or service failed
    // Return cached data or default response
    return getCachedOrder(orderId) || {
      error: 'Service temporarily unavailable',
      orderId
    };
  }
}

Security in microservices is about defense in depth. No single measure is enough. You need authentication between services, encrypted communication, authorization policies, rate limiting, circuit breakers, comprehensive logging, and monitoring. It's more work than a monolith, but it's the price of distributed systems. Automate what you can with service meshes and API gateways, and make security a requirement from day one, not an afterthought.