12c8615615
Adds accounting-service PATCH/archive, fiscal helpers, COA templates and setup status, plus SuperApp Accounting UI (DS, scoreboard, masters, vouchers, ledger, ops modules) with session refresh and HTTPS public API URLs. Co-authored-by: Cursor <cursoragent@cursor.com>
42 lines
1.2 KiB
Markdown
42 lines
1.2 KiB
Markdown
# ADR-003: Row-Level Multi-Tenancy with tenant_id
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| Status | Accepted |
|
|
| Date | 2025-01-01 |
|
|
| Deciders | Platform Architecture |
|
|
| Supersedes | — |
|
|
| Superseded by | — |
|
|
|
|
## Context
|
|
|
|
Every business module must isolate tenant data. Database-per-tenant is operationally heavy for early phases.
|
|
|
|
## Decision
|
|
|
|
Use shared databases per service with mandatory `tenant_id` on every business table. Tenant resolution order: `X-Tenant-ID` → `X-Tenant-Slug` → subdomain → custom domain → user `current_tenant_id`. Cross-tenant queries are forbidden.
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
|
|
- Simple ops on a single DB per service
|
|
- Consistent middleware and repository filters
|
|
- Compatible with subdomain and custom-domain white-label
|
|
|
|
### Negative
|
|
|
|
- Requires rigorous tenant filters in every query
|
|
- Noise-neighbor risk at very large scale (future mitigation possible)
|
|
|
|
## Alternatives Considered
|
|
|
|
1. Database-per-tenant
|
|
2. Schema-per-tenant
|
|
|
|
## Related Documents
|
|
|
|
- [Multi-Tenant Architecture](../multi-tenant-architecture.md)
|
|
- [Security Architecture](../security-architecture.md)
|
|
- [Project Principles](../../development/project-principles.md)
|