microservices

Microservices Architecture

Overview

Microservices decompose an application into small, independently deployable services organized around business capabilities. Each service owns its data and communicates via APIs or events.

Service Design

Service Boundaries

✅ Good boundaries (aligned with business capabilities):
┌──────────┐  ┌───────────┐  ┌──────────┐  ┌───────────┐
│  Users   │  │  Orders   │  │ Payments │  │ Shipping  │
│          │  │           │  │          │  │           │
│ - Auth   │  │ - Cart    │  │ - Charge │  │ - Track   │
│ - Profile│  │ - Checkout│  │ - Refund │  │ - Fulfill │
│ - Prefs  │  │ - History │  │ - Ledger │  │ - Label   │
└──────────┘  └───────────┘  └──────────┘  └───────────┘

❌ Bad boundaries (tech layers):
┌──────────┐  ┌───────────┐  ┌──────────┐
│ Frontend │  │  Backend  │  │ Database │  ← Not microservices
└──────────┘  └───────────┘  └──────────┘

Communication

Synchronous (request/response):
  REST API   — Simple CRUD, public APIs
  gRPC       — Internal service-to-service, streaming

Asynchronous (event-driven):
  Message Queue (RabbitMQ, SQS) — Task processing, commands
  Event Stream (Kafka)          — Event sourcing, data sync

Core Patterns

API Gateway

# Route external requests to internal services
routes:
  /api/users/*:    upstream: http://user-service:3000
  /api/orders/*:   upstream: http://order-service:3000
  /api/payments/*: upstream: http://payment-service:3000

# Cross-cutting concerns at the gateway:
# - Authentication / JWT validation
# - Rate limiting
# - Request logging
# - Response caching

Service Communication

// Sync: REST with circuit breaker
import CircuitBreaker from 'opossum';

const paymentBreaker = new CircuitBreaker(
  async (orderId: string) => {
    return fetch(`http://payment-service/charges/${orderId}`);
  },
  { timeout: 3000, errorThresholdPercentage: 50, resetTimeout: 30000 }
);

// Fallback when circuit is open
paymentBreaker.fallback(() => ({ status: 'pending', message: 'Payment service unavailable' }));