TorbatYar/docs/architecture/adr/ADR-001.md
Mortezakoohjani 12c8615615 Ship enterprise Accounting FE/API with CRUD parity and production wiring.
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>
2026-07-24 15:26:43 +03:30

1.3 KiB

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