RELEASE PLAN — PHASE 15

VietGara — Scale

Version 15.0 — October 9, 2026 · Cloud: Google Cloud Platform (GCP) · Backend: Go

1. Introduction

Phase 15 (per Vision & Scope Section 3.2) focuses on scale: splitting services based on actual load (the final stage of ADR-001), database silos for large tenants, advanced multi-branch dashboards and exports, and moving stock between an owner’s garages. It is more about operational optimization than new core business features, and the load profile and metrics of Phase 9 provide the evidence for what to split.

2. Overview of the 4 Releases

Release	Name	Main Modules	Value Achieved
15.0	Service Split	All remaining modules in the Modular Monolith	Each module runs independently, deployed and scaled separately
15.1	Multi-Tenancy Silo	Tenant/Garage, database provisioning	Large garages get a dedicated database schema on demand
15.2	Reporting CQRS & Multi-Garage Dashboard	Reporting Service	Fast consolidated dashboard and custom exports for chains
15.3	Transfers Between Garages	Inventory	An owner moves stock between their garages with a two-step document

3. Release Details

Release 15.0 — Splitting Services Out of the Modular Monolith

Applies the exact criteria in ADR-001: split when a service already has a dedicated team and an independent change frequency high enough that sharing a repository and runtime would bottleneck CI or scaling. this release splits the modules in the order of measured load: Repair Order (the one the mobile apps and the real-time channel touch most), then Inventory and Quote, which usually peak at busy hours (the load profile and metrics of Phase 9 provide the evidence).

Split the Repair Order, Inventory and Quote services out of vietgara-backend into independent Go services deployed separately (in the namespaces of Deployment Architecture Section 5), through the Terraform of Release 9.2.
Establish real gRPC clients between the split services (previously direct calls inside one process).
Definition of Done: the Inventory Service scales to more replicas at peak without affecting other services; all existing integration tests still pass after the split.

Release 15.1 — Multi-Tenancy Silo for Large Tenants

Backend: a mechanism to provision a dedicated database schema for a garage or chain on request (ADR-005 hybrid model) and an automated migration tool to apply schema changes to silo tenants.
Data access layer: dynamic routing; each service decides from garage_id whether to query the pooled or the silo database, with no effect on business logic (changes only at the repository layer). The file registry keys already carry the garage id.
Definition of Done: a test tenant is moved from pooled to silo with no data loss and no user-perceptible downtime.

Release 15.2 — Reporting CQRS & Advanced Multi-Garage Dashboard

Backend: a dedicated CQRS read model for Reporting (replacing the direct cross-service queries used since Release 1.5), synced through the events of Event Design.
Frontend: a consolidated multi-branch dashboard (FR-RPT-03) for chain owners with several garages; custom report export (FR-RPT-04) with date range, branch and service type, as Excel.
Definition of Done: the consolidated dashboard of an owner with 20 garages loads in under 1 second from the read model, with no more direct queries into other services’ databases.

Release 15.3 — Transfers Between Garages

Transfer document (FR-INV-18). An owner moves parts from one of their garages to another: a transfer from the sending garage, shipped, then received by the receiving garage. Completing the receipt posts the stock-out at the sender and the stock-in at the receiver, in the part’s units, at the sender’s average cost.
Two garages in one operation. Row-level security scopes each request to one garage, so the transfer is two garage-scoped steps linked by a transfer id and an outbox event, never one cross-garage query. Both garages’ staff need the matching permission.
Matching parts. Parts are matched by SKU or barcode between the owner’s garages; a part missing at the receiver is created from the sender’s definition on confirmation.
Definition of Done: an owner sends 10 filters from gara1-1 to gara1-2; stock at the sender falls only on shipping, rises at the receiver only on receipt, and an interrupted transfer can be completed or cancelled with a reversal.

4. Dependency Diagram

flowchart TD
  P14(["Phase 14 complete"]) --> R150["Release 15.0<br/>Service split (based on measured load)"]
  R150 --> R151["Release 15.1<br/>Silo for large tenants"]
  R150 --> R152["Release 15.2<br/>Reporting CQRS + multi-garage dashboard"]
  R152 --> R153["Release 15.3<br/>Transfers between garages"]
  R151 --> DONE(["Phase 15 complete"])
  R153 --> DONE

Releases 15.1 and 15.2 can run in parallel once 15.0 is complete, since they affect different layers (data isolation versus read model). Transfers use the multi-garage view of 15.2 and, in a silo, the routing of 15.1.