4 Quyết định HĐQT cần lock — Giải thích chi tiết

Tại sao cần 4 quyết định này TRƯỚC khi code?

4 quyết định dưới đây là nền tảng kiến trúc — giống như chọn móng nhà. Nếu sau này đổi móng, phải đập cả nhà. Cụ thể:

• Q1 (Tenant model): Quyết định cách lưu data cho nhiều khách hàng. Đổi → phải migrate lại cả 71 bảng DB.
• Q2 (Ứng lương): Quyết định doanh thu + tuân thủ pháp luật. Đổi → block tính năng P4 (tháng 10-13).
• Q3 (Tenant type): Quyết định nhóm khách hàng phục vụ. Đổi → domain model P2 phải redesign.
• Q4 (Chat-service rename): Quyết định cách cắt service cũ. Đổi → downtime production chat.

Cách đọc trang này: Mỗi câu hỏi gồm 4 phần:

Vấn đề là gì — diễn giải bằng ngôn ngữ phi kỹ thuật
Các lựa chọn — pros/cons, chi phí, rủi ro
Khuyến nghị — đội tech gợi ý + lý do
HĐQT cần quyết — checklist tick chọn

Quyết định 1

🏢 Mô hình lưu dữ liệu đa khách hàng

Rủi ro cao nếu đổi sau

1. Vấn đề là gì?

V4 là SaaS đa tenant — nghĩa là 1 phần mềm phục vụ nhiều khách hàng (nhà máy A, B, C... cùng dùng). Mỗi khách hàng chỉ thấy dữ liệu của mình, không thấy của khách hàng khác.

Câu hỏi kỹ thuật: lưu dữ liệu của nhiều khách hàng này như thế nào?

Hình dung: bạn có 1 tủ hồ sơ. Có 2 cách sắp xếp hồ sơ của 10 công ty khác nhau:

🅰️ Cùng 1 ngăn, mỗi hồ sơ có nhãn tên công ty → khi cần, lọc theo nhãn
🅱️ Mỗi công ty 1 ngăn riêng → mở đúng ngăn của công ty đó

2. Các lựa chọn

Lựa chọn A (khuyến nghị)

🅰️ Một DB chung, có cột `tenant_id`

Tất cả data trong 1 DB, mỗi bản ghi có nhãn tenant_id để biết thuộc khách hàng nào.

✅ Ưu điểm

Triển khai nhanh (6-8 tuần)
Backup/maintenance 1 lần cho tất cả
Dùng lib có sẵn: stancl/tenancy (4K sao GitHub)
Query cross-tenant để BOD xem tổng quan dễ
Hạ tầng rẻ — 1 MySQL server

⚠️ Nhược điểm

Nếu bug filter → rò rỉ data cross-tenant (phải pentest kỹ)
Khách hàng enterprise khó chấp nhận "cùng DB với khách khác"

Lựa chọn B

🅱️ Mỗi tenant 1 DB riêng

Mỗi khách hàng có 1 database hoàn toàn riêng. Ứng dụng switch connection tùy khách.

✅ Ưu điểm

Isolation tuyệt đối — không rò rỉ
Dễ bán enterprise (khách có DB riêng họ tin tưởng hơn)
Xoá khách = drop DB, dễ GDPR compliance

⚠️ Nhược điểm

Triển khai chậm (12-16 tuần)
Backup × N tenant = ops team lớn
Migration khi update schema = chạy N lần
Chi phí hạ tầng 3-5× (N database instance)
Query tổng quan BOD = phải aggregate N DB

3. So sánh chi phí thực tế

Chiều	Lựa chọn A	Lựa chọn B
Effort triển khai	60 PW	120 PW
Timeline	4 tháng	7-8 tháng
Hạ tầng ($/tháng, 50 tenants)	~$500	~$2,500
DevOps effort	Thấp	Cao (backup × N)
Risk cross-tenant leak	Trung bình	Thấp

4. Khuyến nghị của đội tech

Chọn A (1 DB + tenant_id). Lý do:

V4 phase đầu (P2) — cần lên nhanh, 1 canary customer pilot
Team chưa có DevOps đủ mạnh để quản N database instance
Nếu sau 1 năm có enterprise customer yêu cầu DB riêng → stancl/tenancy hỗ trợ cả 2 mode, migrate được 1 khách cụ thể sang mode B mà không ảnh hưởng khác.

5. HĐQT cần quyết

☑️ Chọn 1 trong 3:

A — Một DB, cột tenant_id (khuyến nghị)

Triển khai nhanh, chi phí thấp, pentest kỹ

B — Mỗi tenant 1 DB riêng

Tuyệt đối isolation, chi phí cao hơn 3-5×

C — Hybrid: mặc định A, enterprise tier B

Bán 2 gói giá khác nhau

Quyết định 2

💰 Mô hình ứng lương cho công nhân

Legal + Revenue

1. Vấn đề là gì?

Trong V4, VIỆC XANH 247 có tính năng ứng lương — công nhân đi làm 20 ngày có thể ứng trước 50% lương mà không cần chờ đến cuối tháng.

Ai đưa tiền cho công nhân? Có 2 hướng:

🅰️ VIỆC XANH tự cho vay — dùng vốn công ty, thu phí, lãi tự quản
🅱️ Partner fintech cho vay — VIỆC XANH chỉ là kênh giới thiệu, phí commission

⚠️ Ảnh hưởng pháp lý quan trọng: Tự cho vay ở VN cần giấy phép Tổ chức tín dụng phi ngân hàng của NHNN (Ngân hàng Nhà nước). Thời gian xin: 6-12 tháng. Vốn pháp định: 500 tỷ VND. Nếu không có license mà vẫn cho vay thu lãi → phạt hành chính + hình sự.

2. Các lựa chọn

Lựa chọn A

🅰️ VIỆC XANH tự cho vay

Dùng vốn công ty (hoặc huy động). Thu phí dịch vụ + có thể lãi.

✅ Ưu điểm

Lợi nhuận cao (100% phí về VIỆC XANH)
Chủ động product, UX mượt
Data credit scoring giữ lại nội bộ
Không phụ thuộc partner

⚠️ Nhược điểm

Cần license NHNN (6-12 tháng)
Vốn pháp định 500 tỷ
Gánh rủi ro nợ xấu (default rate)
Tuân thủ KYC/AML phức tạp
Kế toán thuế đặc thù tổ chức tín dụng

Lựa chọn B (khuyến nghị giai đoạn 1)

🅱️ Partner với fintech có license

Tìm fintech đã có license (Gimo, Vui App, Fundiin, MOMO...). VIỆC XANH lo data + UX, partner lo tiền + compliance.

✅ Ưu điểm

Triển khai ngay không cần license
Không gánh rủi ro nợ xấu
Partner lo KYC/compliance
Vốn pháp định 0
Revenue: commission 10-20% mỗi khoản vay

⚠️ Nhược điểm

Biên lợi nhuận thấp hơn
Phụ thuộc chính sách partner
Data sharing phức tạp (GDPR-like)
UX có thể không mượt 100%

3. Chiến lược đề xuất (Hybrid timeline)

Giai đoạn	Mô hình	Lý do
Năm 1 (P4)	🅱️ Partner fintech	Launch nhanh, không chờ license, học behavior
Năm 2-3	🅱️ Partner + xin license	Có data credit, có doanh thu → đủ sức xin license
Năm 3+	🅰️ Tự vận hành	Khi có license → migrate dần, biên lợi nhuận cao

4. Khuyến nghị

Chọn B cho Năm 1. Đồng thời bắt đầu quy trình xin license song song (mất 6-12 tháng). Sau khi có license + đủ data → chuyển dần sang A.

Partner candidate: Gimo (chuyên EWA Việt Nam), Fundiin (BNPL nhưng có EWA), MoMo (scale lớn).

5. HĐQT cần quyết

A — Tự cho vay từ đầu

Delay P4 6-12 tháng chờ license, cần chuẩn bị 500 tỷ vốn

B — Partner fintech (khuyến nghị)

Launch đúng timeline, commission 10-20%

C — Hybrid: Partner P4, tự vận hành Năm 3+

Dual track: launch với partner, xin license song song

Cần thông tin: HĐQT có cam kết vốn 500 tỷ cho option A/C không? Timeline được đẩy giúp năm 3 tự vận hành?

Quyết định 3

🏷️ Phân loại khách hàng (tenant type)

Ảnh hưởng product

1. Vấn đề là gì?

V4 có 2 nhóm khách hàng chính: nhà máy (dùng tính năng quản lý công nhân, chấm công, lương) và nhà cung ứng lao động (dùng tính năng tuyển dụng, quản lý cộng tác viên, hoa hồng).

Câu hỏi: Phân loại tenant cứng hay linh hoạt?

Thực tế thị trường: có công ty vừa là nhà cung ứng, vừa vận hành nhà máy (hybrid). Có công ty ban đầu chỉ tuyển dụng, sau mở nhà máy của riêng mình. Nếu phân loại cứng → phải tạo 2 tài khoản riêng cho cùng 1 công ty → data phân mảnh.

2. Các lựa chọn

🅰️ Cứng 2 loại

tenant_type = 'factory' | 'supplier'. Mỗi tenant chỉ 1 loại.

Logic đơn giản
Sales pricing rõ ràng
Hybrid company phải tạo 2 account
Dữ liệu công nhân không liên thông giữa 2 account

🅱️ Flexible 3 loại

tenant_type = 'factory' | 'supplier' | 'hybrid'. Hybrid bật cả 2 module set.

Bám sát thị trường thực
1 company = 1 tenant dù mô hình nào
Upsell: factory → hybrid khi khách mở thêm dịch vụ
Logic phức tạp hơn 10-15%

🅲️ Module-based (không type)

Không có loại tenant. Chỉ có module bật/tắt. Khách bật module gì thì thành loại đó.

Linh hoạt tuyệt đối
Bán pricing theo module
Onboarding khó (khách phải hiểu chọn module nào)
Sales phức tạp

3. Khuyến nghị

Chọn B (flexible 3 loại). Lý do:

Thị trường VN có nhiều công ty hybrid (ví dụ: công ty cung ứng tự vận hành nhà máy gia công may)
UX đơn giản: sales hỏi "anh/chị thuộc nhóm nào" → chọn 1 trong 3
Pricing dễ: 3 gói rõ ràng
Option C quá linh hoạt, sales team khó bán, khách khó hiểu

4. HĐQT cần quyết

A — Cứng 2 loại (factory | supplier)

B — Flexible 3 loại (+ hybrid) (khuyến nghị)

C — Module-based (không fixed type)

Câu hỏi phụ cho sales: Trong 20 khách target đầu tiên, có bao nhiêu là hybrid?

Quyết định 4

🔄 Cách rename chat-service → ai-orchestrator

Production downtime

1. Vấn đề là gì?

Hiện có service chat-service (Node.js, NestJS) đang chạy production cho chat. V4 muốn mở rộng service này thành AI Orchestrator — điều phối tất cả AI agents, không chỉ chat.

Câu hỏi: Rename + expand như thế nào để không ảnh hưởng chat production?

2. Các lựa chọn

🅰️ In-place rename + redeploy

Đổi tên thư mục, update config, deploy. Downtime 4-8h.

Nhanh, đơn giản
Downtime chat production
Nếu rollback phải redeploy lại

🅱️ Dual-run (blue-green)

Deploy ai-orchestrator mới song song với chat-service cũ. Frontend gọi theo feature flag. Cutover dần, downtime 0.

Zero downtime
Rollback tức thì (đổi feature flag)
A/B test được response quality
Chi phí hạ tầng 2× trong 2 tuần
DB migration cần backward-compat

🅲️ Tạo mới hoàn toàn

Không rename. Tạo ai-orchestrator mới, chat-service giữ nguyên. 2 services.

Không đụng vào chat-service
Scope rõ ràng
2 service bảo trì vĩnh viễn
Logic AI duplicate

3. Khuyến nghị

Chọn B (dual-run 2 tuần, rồi decommission chat-service).

Timeline cụ thể:

Week 1-2: Deploy ai-orchestrator side-by-side, không traffic
Week 3: Chuyển 5% chat traffic sang ai-orchestrator
Week 4: 50% traffic nếu OK
Week 5: 100% traffic
Week 6: Decommission chat-service

4. HĐQT cần quyết

Quyết định này thiên về tech, BOD chủ yếu duyệt budget hạ tầng tăng tạm thời.

A — In-place rename (downtime 4-8h)

Chi phí 0, nhưng mất chat 4-8 giờ

B — Dual-run blue-green (khuyến nghị)

+$300 hạ tầng × 6 tuần = ~$450, downtime 0

C — Giữ 2 services riêng

Maintenance cost 2× vĩnh viễn

📋 Tóm tắt quyết định

#	Câu hỏi	Khuyến nghị	Ảnh hưởng nếu đổi sau
Q1	Multi-tenant data model	A — 1 DB + tenant_id	Rewrite 71 bảng (~3 tháng)
Q2	Ứng lương funding	C — Hybrid: partner P4, tự vận hành 3+	Block P4 6-12 tháng chờ license
Q3	Tenant type	B — Flexible 3 loại	Redesign domain model (~1 tháng)
Q4	Chat-service rename strategy	B — Dual-run blue-green	Downtime 4-8h production chat

⏰ Deadline lock quyết định: Tuần 1 của Phase 1 (tuần tới). Nếu không lock đúng hạn, dev team sẽ phải blocked chờ → slippage 1-2 tuần mỗi câu hỏi.

Sau khi BOD ký

Tạo file docs_v4/decisions-260421-locked.md ghi quyết định
Cập nhật plans/260414-2143-v4-techstack-brief/plan.md (mục Unresolved → Resolved)
Trigger tạo 3 plan chi tiết:
- P1 Foundation detailed (12 tuần)
- Permission DB migration (risk cao)
- Trust Layer design (5 tables)
Kickoff meeting dev team + start code tuần 2

📖 Thuật ngữ giải thích

Tenant: 1 khách hàng dùng phần mềm. VIỆC XANH X phục vụ nhiều tenant cùng lúc (SaaS).
Multi-tenant: 1 phần mềm, nhiều khách hàng dùng chung, dữ liệu mỗi khách hàng tách riêng.
tenant_id: Một số (ID) gắn vào mỗi dòng dữ liệu để biết dòng đó thuộc tenant nào. Khi query, luôn lọc theo tenant_id.
Pentest (Penetration test): Thuê đội bảo mật tấn công vào hệ thống để tìm lỗ hổng trước khi hacker thật tìm ra.
EWA (Earned Wage Access): Ứng lương — công nhân lấy lương đã đi làm được trước ngày nhận lương chính thức.
License NHNN (Tổ chức tín dụng phi ngân hàng): Giấy phép cho vay tiền ở Việt Nam. Yêu cầu vốn 500 tỷ + 6-12 tháng xét duyệt.
Blue-green deploy: Kỹ thuật deploy phiên bản mới song song với cũ. Switch traffic dần. Zero downtime.
Feature flag: Công tắc bật/tắt tính năng runtime, không cần deploy code mới.
Orchestrator: Bộ điều phối. AI Orchestrator = hệ thống routing câu hỏi đến đúng AI agent chuyên biệt.
Canary rollout: Release từng bước: 5% users → 50% → 100%. Giống chim hoàng yến trong mỏ than — thử trước để phát hiện lỗi.
Phase gate: Điểm kiểm soát cuối mỗi phase. Không pass gate = không qua phase sau.