Cloud Computing Architecture Guide

Service Boundaries, Data Ownership, and Tenant Context

Goal

Connect business capability, team ownership, data authority, and verified tenant context to credible service boundaries.

The Short Version

A service boundary is credible when one owner can change its behavior and authoritative data through explicit contracts. A separate repository or endpoint is not enough. Shared writes, coordinated releases, and unclear authority preserve hidden coupling.

Data ownership does not require one physical database server per service. It requires one authoritative writer and controlled access. Other services obtain data through an API, consume published facts, or maintain derived read models with known freshness and reconciliation behavior.

Authority and Contracts

Verified tenant context
          |
          v
+-------------------+       API/event contract       +-------------------+
| Order boundary    | ------------------------------> | Inventory boundary|
| order authority   |                                 | stock authority   |
+-------------------+                                 +-------------------+
        |                                                       |
   owned writes                                              owned writes

Stable boundaries often align with a cohesive business capability, a clear vocabulary, a distinct change cadence, and an accountable team. They should minimize the number of invariants that require two owners to coordinate.

The inventory service owns whether stock can be reserved. The order service owns order status. Order code must not update inventory tables directly. It can request a reservation and record the result, while inventory publishes changes other consumers may use. A reporting service may build a local read model from those facts, but it must tolerate delay and reconcile gaps.

Tenant Context Is Security Context

In SaaS, tenant identity must be established from a trusted authentication or routing context, propagated with each request and message, enforced in authorization and data access, and retained in audit evidence. A caller-supplied tenantId is data, not proof.

Use tenant context in partition keys, quotas, logs, and cost allocation only after validation. Background work must carry the same trusted context, and support tooling must make cross-tenant access explicit, time-bounded, and auditable.

Example: Orders and Inventory

A retailer places an order for tenant North. The API validates the caller and binds the request to North. The order boundary creates a pending order and requests inventory reservation with an idempotency key and verified tenant context. Inventory alone decides whether stock is available. Its result moves the order forward or rejects it.

Both teams can evolve storage independently because their shared commitment is the contract. A derived availability view can improve reads, but checkout still uses the authoritative reservation operation.

Common Mistakes

  • Equating table groups with service boundaries.

  • Claiming ownership while allowing cross-service database writes.

  • Trusting tenant identifiers from unverified callers.

  • Building read models without freshness, gap detection, or rebuild plans.

  • Splitting responsibilities that still share one inseparable business invariant.

If Someone Asks You

Should each service own its own database?

"Each service should own its authoritative data and write path. Physical separation can follow risk, scale, and operating needs, but other services should not bypass the owner's contracts even if storage is initially shared."

What You Should Remember

Data authority matters more than physical database separation on day one.

Questions to Check Your Understanding

  1. What makes a data owner authoritative?

  2. How can another service maintain a safe local read model?

  3. At which boundaries must tenant context be verified or propagated?

Further Study