Tight Coupling Between Services — When Changing One Service Breaks Five Others

❌ Distributed monolith:

User API → synchronously calls → Order Service
Order Service → synchronously calls → Inventory Service
Order Service → synchronously calls → Payment Service
Payment Service → synchronously calls → User API (circular!)

Problems:
- Chain of synchronous calls: one service down = all down
- Deploy order matters (Payment must deploy before Order)
- API contract changes in User API break Order and Payment
- Latency stacks: 50ms + 80ms + 60ms + 40ms = 230ms minimum
- Circular dependency makes reasoning about the system impossible

// ❌ Synchronous chain — fragile
class OrderService {
  async createOrder(data: CreateOrderDto) {
    // Synchronously call 3 other services
    const user = await userServiceClient.getUser(data.userId)     // 50ms
    const inventory = await inventoryClient.reserve(data.items)   // 80ms
    const payment = await paymentClient.charge(data.total)        // 200ms

    // If ANY of these fail, the whole order fails
    // If payment service is slow, user waits 330ms+ just for coordination overhead
    return this.ordersRepo.create({ ...data, payment })
  }
}

// ✅ Async events — resilient
class OrderService {
  async createOrder(data: CreateOrderDto) {
    // Only do what ORDER service owns
    const order = await this.ordersRepo.create({
      ...data,
      status: 'pending',
    })

    // Publish event — don't wait for downstream services
    await eventBus.publish('order.created', {
      orderId: order.id,
      userId: data.userId,
      items: data.items,
      total: data.total,
    })

    return order  // Return immediately, 5ms response time
    // Inventory, payment, notifications handle asynchronously
  }
}

// ❌ Services share internal data structures — any field rename breaks everyone
// In user-service: returns full internal User model
interface User {
  id: string
  internalDbId: number    // internal detail leaked!
  firstName: string
  lastName: string
  emailAddress: string    // later renamed to email
  passwordHash: string    // security sensitive!
  createdTimestamp: Date  // later renamed to createdAt
}

// ✅ Publish a stable public API contract (versioned)
// user-service public API v1 — never changes without versioning
interface UserPublicV1 {
  id: string
  fullName: string   // stable name
  email: string      // stable name
  createdAt: string  // ISO 8601 — stable format
  // Internal fields never exposed
}

// API versioning
app.get('/v1/users/:id', getV1User)  // stable forever
app.get('/v2/users/:id', getV2User)  // new version when contract must change

// Old version deprecated, not removed, for 6+ months
app.get('/v1/users/:id', async (req, res) => {
  res.setHeader('Deprecation', 'version="v1", date="2026-09-01"')
  res.setHeader('Sunset', 'Tue, 01 Sep 2026 00:00:00 GMT')
  return getV1User(req, res)
})

import CircuitBreaker from 'opossum'

// Every service-to-service call gets a circuit breaker
const userServiceBreaker = new CircuitBreaker(
  (userId: string) => userServiceClient.getUser(userId),
  {
    timeout: 3000,          // fail after 3s
    errorThresholdPercentage: 50,  // open after 50% error rate
    resetTimeout: 30000,    // try again after 30s
  }
)

userServiceBreaker.fallback((userId: string) => {
  // Return cached data or a degraded response — don't fail the whole request
  return { id: userId, fullName: 'Unknown User', email: '' }
})

// Now order-service can degrade gracefully if user-service is down
const user = await userServiceBreaker.fire(userId)

❌ Circular:
  Order Service → calls → User Service → calls → Order Service

✅ Fix via events:
  Order Service → publishes 'order.created' event
  User Service → subscribes to 'order.created', updates own data
  No circular call — both services are autonomous