# ADR-001: Database-per-Service

| Field | Value |
| --- | --- |
| Status | Accepted |
| Date | 2025-01-01 |
| Deciders | Platform Architecture |
| Supersedes | — |
| Superseded by | — |

## Context

TorbatYar is a multi-tenant SuperApp that will grow to many business modules. Shared databases create tight coupling, migration contention, and cross-team schema conflicts.

## Decision

Every service owns exactly one database. Cross-service data access is forbidden. Services communicate only via REST API, Webhook, Async Event, and Outbox/Inbox.

## Consequences

### Positive

- Independent schema evolution per service
- Clear ownership boundaries
- Microservice-ready from day one

### Negative

- No cross-DB joins; eventual consistency required
- Duplicate reference data must be synchronized via events/APIs

### Neutral

- Core Platform database (`core_platform_db`) remains the registry for tenants, plans, entitlements, and service discovery

## Alternatives Considered

1. Shared monolithic database with schema prefixes
2. Schema-per-tenant in one database

## Related Documents

- [Database Architecture](../database-architecture.md)
- [Service Architecture](../service-architecture.md)
- [Services Contracts](../../reference/services-contracts.md)