Tư vấn kiến trúc — EU Location, Firestore, VPS (2026-03-11)

Câu hỏi

• Hạ tầng trước ở Asia, nay muốn chuyển toàn bộ location sang EU có đơn giản không?
• Firestore hiện lưu metadata / documents; có nên chuyển toàn bộ về VPS cho gọn không?

Kết luận ngắn

1. Compute đã gần như ở EU rồi: production compute chính đang ở VPS EU; GCP hiện chỉ còn vai trò hỗ trợ data/CDN/backup.
2. Không nên gom toàn bộ về VPS chỉ vì "gọn". Cần tách 3 quyết định: compute, document store, edge/CDN.
3. Nếu ưu tiên đơn giản vận hành + SSOT rõ ràng, hướng hợp lý là:
   • Giữ VPS EU làm production compute duy nhất.
   • Giữ MySQL/PostgreSQL/Qdrant trên VPS theo vai trò hiện có.
   • Với Firestore: không mở rộng phạm vi của nó thêm; chỉ giữ tạm cho Agent Data/document sync nếu chưa có áp lực compliance mạnh. Nếu có yêu cầu EU/data residency rõ, lên kế hoạch rút dần document store khỏi Firestore hoặc tạo đích EU rồi cutover theo lộ trình.
4. Không khuyến nghị dual-SSOT lâu dài giữa Firestore và DB trên VPS.

Cơ sở từ Agent Data

• knowledge/current-state/infrastructure.md: compute chính đã chạy trên VPS; GCP chỉ còn data support.
• knowledge/dev/ssot/vps/vps-architecture.md: VPS production duy nhất, region EU; Firestore là document layer ở GCP.
• knowledge/dev/ssot/data-sync-architecture.md: Firebase đã bỏ ở deploy path; Agent Data là SSOT cho knowledge_*, Directus ↔ Agent Data sync đang chạy.
• knowledge/dev/ssot/data-connection-law.md: yêu cầu SSOT theo loại dữ liệu, cấm 2 SSOT cho cùng một loại; ưu tiên API/flow chuẩn; migration lớn phải theo Shadow Read → Dual-Write → Cutover.
• knowledge/current-state/firebase-hosting-status.md: ai.incomexsaigoncorp.vn vẫn đi qua Firebase Hosting + Cloud Run proxy ở asia-southeast1 trước khi vào VPS.

Khuyến nghị kiến trúc

A. Chuyển "toàn bộ sang EU"

• Compute core: đã đạt mục tiêu phần lớn, vì VPS production ở EU.
• Edge/public web: còn 1 hop Firebase Hosting + Cloud Run proxy ở Asia. Nếu mục tiêu là giảm phụ thuộc Asia, đây là điểm nên xử lý trước.
• Data: Firestore vẫn ở GCP và hiện là điểm cần cân nhắc kỹ nhất nếu muốn EU residency nhất quán.

B. Có nên chuyển hết Firestore về VPS?

• Không nên trả lời bằng cảm tính "cho gọn".
• Nên chỉ chuyển nếu xác định rõ loại dữ liệu nào sẽ đổi SSOT.
• Theo luật hiện hành:
  • Knowledge docs: file gốc ở GCS, metadata ở Directus, vector ở Qdrant; embedding không là SSOT.
  • Firestore trong current-state/vps-architecture đang đóng vai trò document storage/sync cho Agent Data.
• Vì vậy, chuyển Firestore về VPS chỉ đúng khi đồng thời thiết kế lại SSOT rõ ràng cho document layer. Nếu không, sẽ tạo thêm chồng chéo.

C. Phương án đề xuất

Option 1 — Bảo thủ, ít rủi ro nhất

• Giữ Firestore như hiện tại.
• Không tăng thêm use-case cho Firestore.
• Dọn edge Asia trước: bỏ Firebase Hosting proxy hoặc chuyển edge/proxy sang EU.
• Chỉ migrate Firestore khi có lý do pháp lý/chi phí/độ trễ đủ mạnh.

Option 2 — Tái cấu trúc vừa phải, hợp hiến pháp hơn

• Chuyển metadata/document canonical về Directus/MySQL hoặc PostgreSQL trên VPS.
• Agent Data đọc từ kho canonical đó, Qdrant chỉ là projection.
• Firestore chỉ còn vai trò tạm (cache/work) trong giai đoạn chuyển tiếp, sau đó loại bỏ.
• Đây là hướng hợp với nguyên tắc 1 SSOT hơn nếu đội muốn giảm GCP dependency.

Option 3 — Full VPS hóa ngay

• Chuyển document store, metadata, sessions, logs tóm tắt… về VPS trong một đợt.
• Không khuyến nghị ngay lúc này vì độ thay đổi lớn, rủi ro đụng nhiều luồng sync, webhook, indexing.

Quyết định khuyến nghị

Khuyến nghị chọn Option 2, nhưng làm 2 pha:

1. Pha 1: bỏ edge/proxy Asia trước, giữ data layer ổn định.
2. Pha 2: hợp nhất document/metadata SSOT về VPS nếu muốn EU residency và kiến trúc gọn thật sự.

Rủi ro cần tránh

• Vừa đổi region, vừa đổi DB paradigm, vừa đổi sync flow trong cùng một nhịp.
• Để Firestore và VPS DB cùng là nguồn ghi chính quá lâu.
• Chuyển dữ liệu nhưng không cập nhật luật/SSOT document tương ứng.

Luật viện dẫn

• Data Connection Law Điều 2: mỗi loại dữ liệu chỉ có 1 SSOT.
• Data Connection Law Điều 7: chỉ định SSOT theo loại dữ liệu.
• Data Connection Law Điều 11: migration lớn phải theo Shadow Read → Dual-Write → Cutover.
• Data Connection Law Điều 16-17: chỉ đi qua API/flow chuẩn, tránh bypass DB.

Gợi ý hành động tiếp theo

1. Audit chính xác Firestore đang chứa những collection nào: official vs work vs sync.
2. Quyết định đích SSOT cho từng loại collection.
3. Viết migration plan theo 3 pha HP-07/Điều 11.
4. Sau đó mới đụng implementation.