toolz/goplt
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6a172364748eb7e13495646dc4a29e56f77bfe28
goplt/docs/adr/0025-multitenancy-model.md
0x1d 6a17236474 docs: add implementation plan, ADRs, and task tracking system 
- Add comprehensive 8-phase implementation plan (docs/plan.md)
- Add 28 Architecture Decision Records (docs/adr/) covering all phases
- Add task tracking system with 283+ task files (docs/stories/)
- Add task generator script for automated task file creation
- Add reference playbooks and requirements documentation

This commit establishes the complete planning foundation for the Go
Platform implementation, documenting all architectural decisions and
providing detailed task breakdown for Phases 0-8.
2025-11-04 22:05:37 +01:00

1.6 KiB
Raw Blame History

ADR-0025: Multi-tenancy Model

Status

Accepted

Context

The platform may need multi-tenancy support for SaaS deployments. Options:

  1. Shared database with tenant_id column - Single DB, row-level isolation
  2. Schema-per-tenant - Single DB, separate schemas
  3. Database-per-tenant - Separate databases

Each has trade-offs for isolation, performance, and operational complexity.

Decision

Use shared database with tenant_id column (optional feature):

  1. Model: Single PostgreSQL database with tenant_id column on tenant-scoped tables
  2. Isolation: Row-level via Ent interceptors (automatic filtering)
  3. Tenant resolution: From header (X-Tenant-ID), subdomain, or JWT claim
  4. Optional: Can be disabled for single-tenant deployments

Rationale:

  • Simplest operational model (single database)
  • Good performance (can index tenant_id)
  • Easy to implement (Ent interceptors)
  • Can migrate to schema-per-tenant later if needed
  • Flexible (can support both single and multi-tenant)

Consequences

Positive

  • Simple operations (single database)
  • Good performance with proper indexing
  • Easy to implement
  • Flexible (optional feature)

Negative

  • Requires careful query design (ensure tenant_id filtering)
  • Data isolation at application level (not database level)
  • Potential for data leakage if bugs occur

Implementation Notes

  • Make tenant_id optional (nullable) for single-tenant mode
  • Add Ent interceptor to automatically filter by tenant_id
  • Resolve tenant from context via middleware
  • Add tenant_id to JWT claims
  • Document tenant isolation guarantees
  • Consider adding tenant_id to all tenant-scoped tables