decision-canon/examples/DEC-EX-002-schema-ownership.md

DEC-EX-002 — Who owns the service schema

Situation: architecture decision.

Two services already share one database. A third service is about to need tables. The example keeps the sections that were needed to record the commitment and the disagreement. It leaves optionality, evidence, uncertainty, execution, and outcome absent.

decision:
  identity:
    id: DEC-EX-002
    title: Who owns the service schema
    namespace: decision-canon/examples
  question:
    text: Should each service own its database schema, or should services share one schema?
    decision_class: architecture
    trigger: A second service needs tables, and the shared schema already blocks releases.
  kind:
    primary: choice
  state:
    lifecycle: committed
    since: "2026-04-02"
  frame:
    situation: Two services write the same database. Releases wait on each other's migrations.
    scope: New services on this platform. Existing shared tables stay until a later move.
    horizon: The next two years of service splits.
    assumptions:
      - Each service has one team that can review its own migrations.
    exclusions:
      - The database product is out of scope. See DEC-EX-001.
  alternatives:
    - id: A
      label: Service-owned schema
      action: Give each service its own schema and its own migration stream.
      reversibility:
        level: costly
        cost: A data move and a dual-write period.
        delay: One or two release cycles.
    - id: B
      label: Keep the shared schema
      action: Do nothing structural. Coordinate migrations in one queue.
      reversibility:
        level: easy
        delay: none
  values:
    objectives:
      - Services can release without waiting on another team's migration.
    constraints:
      - A migration is reversible, or it is rehearsed before production.
    vetoes:
      - Two services write one table and mean different things by a column.
  world_model:
    causal_model: Separate schemas remove migration coupling. They do not remove cross-service calls.
  analysis:
    analyses:
      - id: a1
        method: expert judgment
        result: Service-owned schemas match how the teams already want to release.
        confidence: high
      - id: a2
        method: expert judgment
        result: One shared schema stays simpler until a third service, and the coupling is still tolerable.
        confidence: medium
    recommendation: Service-owned schema
  commitment:
    selected: A
    by: platform owner
    at: "2026-04-02"
    mode: decided
    confidence: high
  governance:
    owner: platform owner