Overengineering with Microservices Too Early — When Complexity Kills Speed

Startup with 3 engineers and 500 users:

Services deployed:
- user-service
- auth-service
- notification-service
- payment-service
- billing-service
- email-service
- webhook-service
- analytics-service
- search-service
- media-service
- api-gateway
- config-service

Reality:
- Every feature touches 3+ services
- Local dev requires Docker Compose with 12 containers
- A new engineer takes 2 weeks to understand the architecture
- Deploying a simple UI change triggers 4 pipeline runs
- Inter-service calls fail in ways that are hard to debug
- One engineer spends 40% of their time on infra, not features

// Adding a "show user's order history with product details" feature

// Monolith: one function, one database query
async function getUserOrderHistory(userId: string) {
  return db.query(`
    SELECT o.*, p.name, p.image_url
    FROM orders o
    JOIN products p ON o.product_id = p.id
    WHERE o.user_id = $1
    ORDER BY o.created_at DESC
  `, [userId])
}
// Time to implement: 30 minutes
// Deployment: 1 PR, 1 pipeline

// Microservices: coordinate across 3 services
async function getUserOrderHistory(userId: string) {
  // Call order-service
  const orders = await orderServiceClient.getOrdersByUser(userId)

  // Call product-service for each order (N+1 problem now across network)
  const products = await Promise.all(
    orders.map(o => productServiceClient.getProduct(o.productId))
  )

  // Call user-service to verify user exists
  const user = await userServiceClient.getUser(userId)

  return orders.map((o, i) => ({ ...o, product: products[i], user }))
}
// Time to implement: 2 days (service contracts, error handling, timeouts)
// Deployment: 3 PRs across 3 repos, 3 pipelines, coordinate releases
// New failure modes: network timeout, one service down blocks all

When to extract a service:
✅ Different scaling needs (e.g., video processing uses 100x more CPU)
✅ Different deployment cadence (e.g., ML model updates daily, core app monthly)
✅ Different team ownership (e.g., 10+ engineers, clear domain boundary)
✅ Regulatory isolation required (e.g., payment card data must be isolated)
✅ Technology mismatch (e.g., one part needs Python, rest is Node.js)

When NOT to extract a service:
❌ "It feels cleaner"
❌ "Netflix does it"
❌ "What if we need to scale?"
❌ "It'll be easier to work on separately"
❌ You have < 5 engineers
❌ You haven't found product-market fit yet

my-app/
├── src/
│   ├── modules/
│   │   ├── users/          ← clean domain boundary
│   │   │   ├── users.service.ts
│   │   │   ├── users.repository.ts
│   │   │   └── users.types.ts
│   │   ├── orders/
│   │   │   ├── orders.service.ts
│   │   │   ├── orders.repository.ts
│   │   │   └── orders.types.ts
│   │   ├── payments/
│   │   └── notifications/
│   ├── shared/
│   │   ├── database/
│   │   ├── auth/
│   │   └── config/
│   └── app.ts

Stage 1 (0-100k users): Single well-structured monolith
Stage 2 (100k-1M users): Identify actual bottlenecks with profiling
  → Extract only the pieces with PROVEN scaling needs
  → Keep shared database initially (strangler fig pattern)
Stage 3 (1M+ users): Extract more services based on team boundaries
  → Each team owns one service
  → Database per service only after stage 2 proves it's needed