Database Per Service

What actually happens

Try it: choose a cross-service data path

Database-per-service means Order API never opens Customer DB credentials. The question is whether you pay for a synchronous API read, maintain an event projection, or accidentally reintroduce a shared database.

Ownership levels

Shared database vs database per service

Database per service is primarily an ownership rule: a service controls its data model, migrations, and writes. Separate credentials and schemas on one database cluster can enforce that rule initially, although those services still share hardware capacity and outages. Separate clusters add physical isolation at additional cost. Merely creating several databases does not create autonomy if every service still edits its neighbors’ tables.

┌──────────┐ ┌──────────┐ ┌──────────┐
│ Orders   │ │ Users    │ │ Payments │
│ Service  │ │ Service  │ │ Service  │
└────┬─────┘ └────┬─────┘ └────┬─────┘
     │             │             │
     ▼             ▼             ▼
┌─────────────────────────────────────┐
│       SHARED RELATIONAL DATABASE      │
│  orders | users | payments tables    │
└─────────────────────────────────────┘

┌──────────┐ ┌──────────┐ ┌──────────┐
│ Orders   │ │ Users    │ │ Payments │
│ Service  │ │ Service  │ │ Service  │
└────┬─────┘ └────┬─────┘ └────┬─────┘
     │             │             │
     ▼             ▼             ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│Relational│ │ Document │ │Wide-column│
│ (orders) │ │ (users)  │ │(payments) │
└──────────┘ └──────────┘ └──────────┘

Why isolation helps

Independent scaling, blast-radius reduction, and engine choice per workload come from clear data ownership lines.

Challenges: joins and transactions

A local SQL join can combine tables under one engine’s snapshot and transaction rules. Once records belong to separate services, a sequence of API reads may observe different moments in time and fail partway through. Decide whether the product needs a current composed view, a historical snapshot, or a deliberately lagging projection. The solution follows that meaning; replacing each join with an HTTP call can create a slower and less coherent result.

// API Composition Pattern
OrderComposer.getOrderWithUser(orderId):
  order = orderService.getOrder(orderId)       // Call 1
  user  = userService.getUser(order.userId)    // Call 2
  return { ...order, userName: user.name }     // Combine
// Trade-off: 2 network calls vs 1 SQL join
// At scale: use a query layer to batch and parallelize

-- Monolith: All or nothing
BEGIN TRANSACTION
  INSERT INTO orders (...)
  UPDATE inventory SET qty = qty - 1
  INSERT INTO payments (...)
COMMIT  -- guaranteed

Saga pattern

Model a business workflow as steps with explicit undo handlers instead of one giant Atomicity, Consistency, Isolation, Durability (ACID) transaction spanning databases. Use choreography or orchestration.

OrderSvc ──(OrderCreated)──▶ InventorySvc
                               ──(InventoryReserved)──▶ PaymentSvc
                                ──(PaymentCharged)──▶ OrderSvc
                                  → Mark order CONFIRMED

Failure compensation (payment fails):
PaymentSvc ──(PaymentFailed)──▶ InventorySvc
  → Release reserved inventory
  ──(InventoryReleased)──▶ OrderSvc
    → Mark order CANCELLED

API composition and read models

API composition fetches several owners’ answers at request time, which keeps data relatively current but adds latency and dependency failures. A materialized read model copies the fields needed for one query and updates them from events, making reads fast at the cost of storage and lag. For order history, preserve the product name and price accepted at purchase when historical truth matters; the current catalog name answers a different question.

async getOrderHistory(userId) {
  orders = await orderService.getByUser(userId)
  
  // Parallel fan-out for efficiency
  [products, deliveries] = await Promise.all([
    productService.getBatch(orders.map(o => o.productId)),
    deliveryService.getBatch(orders.map(o => o.deliveryId))
  ])
  
  return orders.map(order => ({
    ...order,
    product: products[order.productId],
    delivery: deliveries[order.deliveryId]
  }))
}

Data ownership math

projection_bytes = rows * bytes_per_row * replication_factor
100_000_000 * 1KB * 3 ~= 300GB replicated

backfill_time = rows / rows_per_sec
100_000_000 / 5_000 ~= 20_000s ~= 5.6h

lag_budget = acceptable_staleness - processing_delay
30s user tolerance - 8s processing delay = 22s remaining budget

api_composition_availability = product(required_call_availability)
0.999^4 ~= 99.6% before fallbacks

Event reliability and consistency contracts

Incremental migration

Move in phases: logical schemas and permissions, then read paths via APIs, then writes, reconciliation, and finally separate clusters when risk allows.

-- logical schemas
schema "orders"  → owned by Order Service
schema "users"   → owned by User Service

Anti-patterns

What to say in a design review

Production deep dive: ownership and recovery contract

Migration states for one owned aggregate

SHARED_SOURCE
  -> COPY_SNAPSHOT(checkpoint)
  -> CATCH_UP_CDC(last_source_position)
  -> SHADOW_READ(compare version + semantic fields)
  -> NEW_WRITER(old store receives compatibility events)
  -> NEW_SOURCE_OF_TRUTH(reconciliation SLO healthy)
  -> REMOVE_OLD_ACCESS(after rollback window)

Invariant at every state:
one documented writer owns the aggregate version;
replayed commands/events are idempotent;
rollback never discards writes accepted by the new owner.