Chương 82. Chọn kiến trúc theo giai đoạn

Ở chương trước, ta nói về ước lượng nhanh trước khi thiết kế.

Ước lượng giúp ta thấy:

Traffic.
Data growth.
Job duration.
Worker count.
Provider limit.
Cost.
Peak.
Failure.

Nhưng còn một câu hỏi rất quan trọng:

Hệ thống đang ở giai đoạn nào?

Một prototype chưa có user thật không nên dùng cùng kiến trúc với một hệ thống enterprise phục vụ hàng triệu người.

Một sản phẩm vừa có khách hàng đầu tiên không nên mang toàn bộ độ phức tạp của công ty lớn.

Ngược lại, một hệ thống đã có dữ liệu nhạy cảm, khách trả tiền, SLO rõ và compliance nghiêm không thể vận hành như bản demo.

Thông điệp chính của chương:

> Kiến trúc tốt không phải là kiến trúc hoành tráng nhất. Kiến trúc tốt là kiến trúc phù hợp với giai đoạn hiện tại, biết bảo vệ thứ quan trọng nhất bây giờ, và có đường tiến hóa khi áp lực thật xuất hiện.

---

82.1. Vì sao phải chọn theo giai đoạn?

Kiến trúc là trade-off.

Nếu xây quá đơn giản:

Ra nhanh.
Dễ hiểu.
Ít chi phí.

Nhưng có thể:

Khó scale.
Thiếu audit.
Thiếu reliability.
Khó tách team.

Nếu xây quá phức tạp:

Có vẻ chuyên nghiệp.
Chuẩn bị cho tương lai.

Nhưng có thể:

Ra chậm.
Vận hành khó.
Debug khó.
Chi phí cao.
Team nhỏ không gánh nổi.
Sản phẩm chưa biết đúng nhu cầu đã bị kiến trúc khóa chân.

Không có kiến trúc đúng cho mọi thời điểm.

Cùng một sản phẩm có thể cần kiến trúc khác nhau theo giai đoạn.

Ví dụ AI Judge:

Prototype: chứng minh AI chấm được bài.
MVP: cho vài lớp dùng thật.
Có khách hàng thật: không mất bài, có audit, có queue ổn.
Scale-up: chịu deadline peak, multi-tenant, observability mạnh.
Enterprise: SSO, data residency, SLA, tenant isolation mạnh, audit/compliance.

Mỗi giai đoạn có nỗi đau khác nhau.

Kiến trúc nên giải quyết nỗi đau hiện tại và mở đường cho nỗi đau tiếp theo.

---

82.2. Prototype

Prototype là bản thử để trả lời câu hỏi:

Ý tưởng này có khả năng hoạt động không?

Với AI Judge, prototype có thể chỉ cần chứng minh:

AI đọc được bài.
AI trả điểm và feedback tương đối hợp lý.
Prompt có thể bám rubric.
Giáo viên thấy có giá trị.

Ở giai đoạn này, mục tiêu không phải scale.

Mục tiêu là học nhanh.

Kiến trúc prototype có thể rất đơn giản:

Một app nhỏ.
Một database.
Một form upload.
Gọi model trực tiếp.
Lưu kết quả cơ bản.
Một màn hình xem kết quả.

Không cần:

Microservices.
Kubernetes.
Kafka.
Multi-region.
Plugin system.
Full observability stack.

Nhưng ngay cả prototype cũng nên tránh một số thói quen xấu:

Hardcode secret trong code.
Lưu dữ liệu nhạy cảm bừa bãi.
Không ghi prompt/model dùng để test.
Không có cách biết case nào tốt/xấu.

Prototype có thể thô.

Nhưng đừng để nó tạo hiểu lầm rằng hệ thống đã production-ready.

---

82.3. Prototype nên tối ưu điều gì?

Prototype nên tối ưu:

Tốc độ học.
Ít code.
Dễ thay đổi.
Dễ demo.
Dễ bỏ đi.

Câu cuối rất quan trọng:

Dễ bỏ đi.

Nhiều prototype trở thành production vì demo thành công.

Rồi team tiếp tục vá lên nó.

Sau vài tháng, hệ thống production mang DNA của một bản thử nghiệm.

Đó là rủi ro lớn.

Prototype nên có nhãn rõ:

Đây là bản học.
Không phải nền production.

Nếu prototype thành công, ta có thể dùng bài học để xây MVP có chủ đích hơn.

Không nhất thiết bê nguyên code prototype lên production.

---

82.4. MVP

MVP là Minimum Viable Product.

Không phải bản cẩu thả.

MVP là bản nhỏ nhất đủ để user thật dùng và cho feedback thật.

Với AI Judge, MVP có thể cần:

Đăng nhập.
Tạo assignment.
Học sinh nộp bài.
Lưu bài bền.
Queue chấm bài.
Giáo viên xem kết quả.
Một số trạng thái lỗi rõ.
Basic audit.
Basic monitoring.

MVP không cần mọi tính năng:

Multi-region.
Plugin marketplace.
Advanced analytics.
Realtime collaboration.
Tự động tối ưu prompt.
Enterprise SSO.

Nhưng MVP có user thật nên phải bảo vệ những thứ sống còn:

Không mất bài.
Không lộ dữ liệu.
Không chấm nhầm user.
Không gọi AI vô hạn.
Không để secret lộ.

MVP có thể đơn giản.

Nhưng không được vô trách nhiệm.

---

82.5. Kiến trúc MVP thực dụng

Một kiến trúc MVP tốt thường là:

Modular monolith.
Một database chính.
Object storage cho file.
Queue đơn giản cho background jobs.
Worker xử lý việc lâu.
Basic cache nếu cần.
Basic observability.
Feature flags tối thiểu.

Với AI Judge:

FastAPI/Django/Rails/Laravel/.NET app đều được.
PostgreSQL.
Object storage.
Celery/RQ/Sidekiq/Hangfire hoặc job system tương đương.
Một module AI grading rõ.
Một module billing/usage nếu cần.

Điều quan trọng không phải tên framework.

Điều quan trọng là:

Code có module boundary rõ.
Việc lâu không nằm trong request.
Data model không khóa đường multi-tenant nếu cần.
Prompt/model version được lưu.
Log/metric cơ bản có đủ.

MVP nên ít thành phần để team vận hành nổi.

Nhưng module boundary nên đủ rõ để tách sau nếu áp lực thật xuất hiện.

---

82.6. MVP không nên thiếu gì?

Một số thứ không nên bỏ chỉ vì là MVP:

Authentication đúng.
Authorization backend.
Input validation.
Backup cơ bản.
Error handling cơ bản.
Logging đủ debug.
Secrets management tối thiểu.
Idempotency cho hành động quan trọng.
Status rõ cho job async.

Với AI Judge, MVP không nên thiếu:

Trạng thái submission: received, queued, grading, graded, failed, needs_review.
Lưu file bài làm bền.
Không trả success trước khi lưu bài.
Retry AI có giới hạn.
Không double-charge nếu có credit.
Prompt/model version.
Basic admin/support view.

Những thứ này không phải luxury.

Chúng là nền để user thật không bị đau.

MVP cắt tính năng phụ.

Không cắt sự đúng đắn của luồng chính.

---

82.7. Có khách hàng thật

Khi có khách hàng thật, hệ thống bước sang giai đoạn khác.

Giờ không chỉ cần:

Demo chạy.

Mà cần:

User thật tin được.
Support xử lý được.
Ops quan sát được.
Dữ liệu không mất.
Bug có thể điều tra.
Deploy không quá sợ.

Với AI Judge, khách hàng thật sẽ hỏi:

Bài của học sinh có mất không?
Điểm này do AI hay giáo viên sửa?
Vì sao bài này chậm?
Tháng này dùng bao nhiêu credit?
Có export được dữ liệu không?
Ai đã xem/sửa điểm?

Lúc này cần tăng đầu tư vào:

Audit log.
Observability.
Backup/restore test.
Runbook.
Support tooling.
Tenant-aware permission.
Usage tracking.
Data retention.

Không cần scale như công ty lớn.

Nhưng cần vận hành có trách nhiệm.

---

82.8. Dấu hiệu đã qua giai đoạn MVP

Một số dấu hiệu:

Khách hàng trả tiền.
Dữ liệu production có giá trị thật.
Support ticket xuất hiện thường xuyên.
Một lỗi nhỏ ảnh hưởng uy tín.
Deploy làm team căng thẳng.
Không ai biết vì sao job chậm.
Không restore được dữ liệu test.
Không giải thích được billing/usage.

Khi thấy những dấu hiệu này, không nên tiếp tục vận hành như prototype/MVP nonchalant.

Cần thêm kỷ luật:

CI/CD rõ hơn.
Migration cẩn thận hơn.
Monitoring dashboard.
Alert gắn SLO.
Backup restore drill.
Permission tests.
Incident process nhẹ.

Đây là lúc "chạy được" không còn đủ.

"Giải thích được và phục hồi được" bắt đầu quan trọng.

---

82.9. Scale-up

Scale-up là khi hệ thống bắt đầu chịu tải lớn hơn và tổ chức phát triển hơn.

Áp lực có thể đến từ:

Nhiều user hơn.
Nhiều tenant hơn.
Peak traffic cao hơn.
Data lớn hơn.
Nhiều developer hơn.
Nhiều module hơn.
Nhiều integration hơn.
Cost lớn hơn.

Lúc này, vấn đề không chỉ là server chịu nổi không.

Mà là:

Team có deploy độc lập được không?
Database có nghẽn không?
Queue có backlog không?
Tenant lớn có ảnh hưởng tenant nhỏ không?
Cost AI có kiểm soát không?
Logs/metrics có quá đắt không?

Scale-up có thể cần:

Tách worker pool.
Tách queue theo loại job.
Read replica.
Cache có chủ đích.
Search index.
Rate limit/quota theo tenant.
Better model gateway.
Data lifecycle.
Canary deploy.
Stronger observability.

Không nhất thiết cần microservices ngay.

Nhiều hệ thống scale-up rất tốt bằng modular monolith + hạ tầng đúng.

---

82.10. Scale-up không đồng nghĩa microservices

Một lỗi phổ biến:

Hệ thống lớn hơn -> phải microservices.

Không luôn đúng.

Microservices giải quyết một số áp lực:

Team ownership.
Deploy độc lập.
Scale độc lập.
Fault isolation.
Công nghệ khác nhau theo domain.

Nhưng microservices tạo chi phí:

Distributed transactions.
Network failure.
Contract testing.
Observability phức tạp.
Data consistency.
Dev environment khó hơn.
Deployment nhiều hơn.

Nếu team nhỏ, domain chưa ổn, observability yếu, microservices có thể làm mọi thứ tệ hơn.

Trước khi tách service, hãy hỏi:

Module này có ownership riêng chưa?
Có cần scale riêng không?
Contract có ổn định không?
Data boundary có rõ không?
Team có vận hành được không?

Tách service là quyết định tổ chức và vận hành, không chỉ là kỹ thuật.

---

82.11. Enterprise

Enterprise là giai đoạn khách hàng lớn đòi hỏi nhiều hơn.

Yêu cầu có thể gồm:

SSO/SAML/OIDC.
SCIM user provisioning.
Data residency.
Audit log đầy đủ.
SLA.
Custom retention.
Dedicated environment.
Customer-managed keys.
Advanced permissions.
Legal/compliance review.
Support process.
Private networking.

Với AI Judge, trường hoặc tập đoàn giáo dục lớn có thể hỏi:

Dữ liệu học sinh có đi ra region không?
AI provider có dùng dữ liệu để train không?
Ai trong công ty bạn xem được bài làm?
Có export/delete theo tenant không?
Có audit support access không?
Có uptime cam kết không?

Enterprise architecture cần nghiêm túc hơn.

Nhưng không nên xây tất cả enterprise features trước khi có khách enterprise thật.

Nên biết đường tiến hóa.

Ví dụ data model nên không làm data residency impossible.

Audit nền nên có từ sớm.

Nhưng customer-managed keys có thể để sau khi có nhu cầu thật.

---

82.12. Kiến trúc nên tiến hóa theo áp lực thật

Một nguyên tắc hay:

Để áp lực thật kéo kiến trúc tiến hóa.

Áp lực thật có thể là:

Database query chậm đo được.
Queue backlog vượt SLO.
Cost AI tăng rõ.
Team deploy đụng nhau liên tục.
Tenant enterprise cần isolation.
Support không debug được incident.
Audit/compliance trở thành yêu cầu bán hàng.

Áp lực giả là:

Công ty lớn dùng Kafka nên ta cũng dùng.
Nghe microservices chuyên nghiệp hơn.
Sợ sau này scale nên làm distributed từ đầu.
Muốn dùng công nghệ mới.

Áp lực thật có metric, ticket, customer, cost, incident hoặc team pain.

Áp lực giả thường là cảm giác.

Kiến trúc nên phản ứng với áp lực thật.

Không nên chạy theo hình ảnh của công ty khác.

---

82.13. Đừng dùng kiến trúc của công ty lớn cho sản phẩm chưa có người dùng

Kiến trúc của công ty lớn phản ánh vấn đề của họ.

Ví dụ họ có:

Hàng nghìn engineer.
Hàng trăm service.
Traffic toàn cầu.
Compliance nhiều quốc gia.
Đội platform riêng.
Đội SRE riêng.
Data center/region phức tạp.

Họ dùng:

Service mesh.
Kafka clusters.
Kubernetes multi-region.
Feature flag platform lớn.
Data lake.
Internal developer platform.

Những thứ đó có lý do.

Nhưng nếu sản phẩm của bạn có:

3 engineer.
10 khách thử nghiệm.
Traffic nhỏ.
Domain còn đổi mỗi tuần.

thì copy kiến trúc đó có thể giết tốc độ học.

Học từ công ty lớn là tốt.

Copy nguyên kiến trúc của họ là nguy hiểm.

Hãy học nguyên tắc, không bê nguyên hình dạng.

---

82.14. Kiến trúc đơn giản không có nghĩa là thiếu chuyên nghiệp

Một modular monolith tốt có thể rất chuyên nghiệp.

Một microservices system tệ có thể rất nghiệp dư.

Chuyên nghiệp không nằm ở số service.

Chuyên nghiệp nằm ở:

Yêu cầu rõ.
Module boundary rõ.
Dữ liệu quan trọng được bảo vệ.
Deploy an toàn.
Observability đủ.
Backup/restore.
Test đúng rủi ro.
Security/permission đúng.
Cost được kiểm soát.

Một hệ thống đơn giản nhưng có những thứ này tốt hơn nhiều so với hệ thống phức tạp nhưng không ai hiểu.

Đừng sợ đơn giản.

Sợ nhất là đơn giản sai chỗ.

Ví dụ:

Không audit điểm chính thức.
Không idempotency giao dịch tiền.
Không permission backend.
Không backup dữ liệu quan trọng.

Đó không phải đơn giản.

Đó là thiếu nền.

---

82.15. Đừng over-engineer, nhưng cũng đừng tự khóa đường

Hai cực đoan:

Over-engineer: xây quá phức tạp trước nhu cầu.
Under-engineer: làm tắt đến mức sau này không thoát được.

Ví dụ over-engineer:

Tách 12 microservices khi chưa có user.

Ví dụ under-engineer:

Không có tenant_id dù biết sản phẩm sẽ bán cho nhiều trường.

Thiết kế tốt ở giữa:

Chưa cần database per tenant.
Nhưng data model có tenant_id rõ.
Chưa cần model gateway phức tạp.
Nhưng mọi AI call đi qua một module/service boundary rõ.
Chưa cần event streaming platform.
Nhưng job async có idempotency và trạng thái.
Chưa cần enterprise audit đầy đủ.
Nhưng hành động quan trọng đã có audit cơ bản.

Đây là nghệ thuật:

Làm đủ cho hiện tại, không phá tương lai gần.

---

82.16. Evolutionary architecture

Evolutionary architecture là kiến trúc có thể tiến hóa.

Không phải vì đoán đúng tương lai.

Mà vì nó giữ một số ranh giới đủ sạch để thay đổi sau này.

Ví dụ:

Module AI grading có boundary rõ.
Sau này có thể tách thành service.

Usage ledger được thiết kế append-only.
Sau này billing phức tạp hơn vẫn có nền.

Submission status rõ.
Sau này thêm realtime/dashboard dễ hơn.

Tenant context đi qua request/job/event.
Sau này multi-tenancy enterprise đỡ đau hơn.

Kiến trúc tiến hóa không có nghĩa là trì hoãn mọi quyết định.

Nó nghĩa là chọn một số quyết định nền tảng đúng:

Data model.
Module boundaries.
Source of truth.
Contracts.
Observability.
Security.

Những thứ này rẻ hơn nếu làm sớm.

Rất đắt nếu sửa muộn.

---

82.17. Khi nào nên tách service?

Tách service nên dựa trên áp lực thật.

Dấu hiệu tốt:

Module có domain boundary rõ.
Team riêng sở hữu module đó.
Module cần scale riêng.
Module có lifecycle/deploy riêng.
Module thường gây lỗi và cần fault isolation.
Data ownership rõ.
Contract ổn định.

Ví dụ AI Judge có thể tách:

Grading service.
Billing/usage service.
Notification service.
Integration service.
Model gateway.

Nhưng không nên tách chỉ vì tên nghe hợp lý.

Nếu mọi module vẫn đổi liên tục cùng nhau, tách service làm chậm.

Nếu data boundary chưa rõ, tách service tạo distributed mess.

Một bước trung gian tốt:

Tách module trong monolith trước.
Ép dùng interface rõ.
Không truy cập database lung tung.
Theo dõi coupling.
Sau đó tách service nếu cần.

Modular monolith là phòng tập cho microservices.

---

82.18. Khi nào nên đầu tư observability mạnh hơn?

Ngay MVP đã cần logging cơ bản.

Nhưng observability nên tăng theo rủi ro.

Dấu hiệu cần đầu tư thêm:

Không biết vì sao job chậm.
Không biết lỗi nằm ở provider hay database.
Không biết tenant nào bị ảnh hưởng.
Alert quá nhiễu hoặc quá thiếu.
Deploy xong không biết metric xấu từ đâu.
Support không trả lời được khách.

Giai đoạn có khách thật nên có:

Structured logs.
Correlation/request id.
Basic metrics.
Error tracking.
Queue metrics.
Provider metrics.
Dashboard chính.

Scale-up cần:

Tracing.
SLO alerts.
Tenant-level visibility.
Cost metrics.
Deploy markers.
Runbooks.

Enterprise cần:

Audit-grade logs.
Access logs.
Compliance reports.
Customer-facing status/usage nếu cần.

Quan sát hệ thống là thứ tăng dần.

Nhưng đừng đợi đến khi cháy mới bắt đầu log có cấu trúc.

---

82.19. Khi nào nên đầu tư security/compliance?

Một số security cơ bản phải có từ đầu:

Auth đúng.
Backend authorization.
Secrets không hardcode.
HTTPS.
Input validation.
Password/session/token an toàn.
Backup dữ liệu quan trọng.

Compliance nâng cao có thể theo giai đoạn.

Nhưng nếu sản phẩm xử lý dữ liệu nhạy cảm, đừng để quá muộn.

Dấu hiệu cần đầu tư:

Khách trả tiền hỏi về audit/security.
Dữ liệu học sinh/bệnh nhân/tài chính.
Enterprise procurement.
Yêu cầu data retention/export/delete.
Support cần truy cập dữ liệu nhạy cảm.
AI prompt logs chứa dữ liệu thật.

Không cần xây cả bộ compliance enterprise ngay.

Nhưng nên có:

Data classification cơ bản.
Audit hành động quan trọng.
Access control rõ.
Retention cho log nhạy cảm.
Vendor/data flow awareness.

Security làm muộn thường không chỉ là thêm tính năng.

Nó có thể buộc sửa data model và luồng vận hành.

---

82.20. Khi nào nên tối ưu cost?

Đừng tối ưu cost quá sớm đến mức làm chậm học hỏi.

Nhưng cũng đừng bỏ qua cost đến khi hóa đơn nổ.

Với AI app, cost nên được đo rất sớm.

Vì AI cost gắn trực tiếp với usage.

Dấu hiệu cần tối ưu:

AI cost tăng nhanh hơn doanh thu.
Prompt dài làm token nhiều.
Retry làm cost tăng.
Shadow/eval chạy quá rộng.
Log/storage tăng mạnh.
Tenant free dùng quá nhiều.

Tối ưu cost theo giai đoạn:

Prototype:

Biết mỗi thử nghiệm tốn bao nhiêu, tránh gọi vô hạn.

MVP:

Đo cost/request/job/tenant.
Budget alert.
Limit output/token.

Scale-up:

Model routing.
Caching.
Quota theo plan.
Batching.
Prompt optimization.

Enterprise:

Cost attribution, chargeback/showback, custom quota.

Cost không nên là điều bất ngờ.

---

82.21. Giai đoạn thay đổi nhưng nợ cũ còn lại

Khi sản phẩm chuyển giai đoạn, kiến trúc cũ có thể trở thành nợ.

Ví dụ:

Prototype gọi model trực tiếp trong controller.
MVP cần queue nhưng code khó tách.
Có khách thật cần audit nhưng data model không lưu actor.
Scale-up cần tenant fairness nhưng job không có tenant_id.
Enterprise cần data residency nhưng logs đã global.

Đây là lý do cần refactor theo giai đoạn.

Không phải refactor cho đẹp.

Refactor để trả nợ đang cản giai đoạn mới.

Một câu hỏi hay:

Nợ nào nếu không trả sẽ làm giai đoạn tiếp theo rất đau?

Trả nợ theo áp lực thật.

Không cần dọn mọi thứ.

Nhưng nợ ở data model, permission, audit, source of truth thường rất đắt nếu để lâu.

---

82.22. Roadmap kiến trúc

Roadmap kiến trúc là kế hoạch tiến hóa theo giai đoạn.

Ví dụ AI Judge:

Giai đoạn MVP:

Modular monolith.
PostgreSQL.
Object storage.
Queue/worker.
Prompt version.
Basic audit.
Basic metrics.

Giai đoạn có khách thật:

Restore drill.
Better support tooling.
Tenant-aware usage.
SLO dashboard.
Feature flag cho prompt/model.

Giai đoạn scale-up:

Model gateway.
Queue partition/priority.
Read model/dashboard.
Cost controls.
Tracing.
Canary/shadow prompt rollout.

Giai đoạn enterprise:

SSO/SCIM.
Advanced audit.
Data residency.
Dedicated tenant option.
Compliance reports.
Customer-specific retention.

Roadmap không cần quá chi tiết.

Nó cần giúp team biết:

Việc gì làm bây giờ.
Việc gì chuẩn bị đường.
Việc gì chưa cần.

---

82.23. AI Judge qua các giai đoạn

Prototype:

Upload bài.
Gọi AI.
Xem feedback.
Lưu vài case để so sánh.

MVP:

User/assignment/submission.
Queue grading.
Status rõ.
Teacher review.
Basic prompt versioning.
Không mất bài.

Có khách thật:

Tenant.
Permission chắc hơn.
Usage tracking.
Audit log.
Backup/restore.
Monitoring queue/provider/cost.
Support tooling.

Scale-up:

Concurrency limits.
Queue priority.
Model gateway.
RAG/knowledge layer nếu cần.
Canary prompt/model.
SLO alert.
Noisy neighbor controls.

Enterprise:

SSO.
Data governance.
Tenant export/delete.
Data residency.
Advanced audit.
SLA.
Dedicated environment option.

Không có giai đoạn nào sai.

Sai là dùng kiến trúc của giai đoạn sau khi chưa cần, hoặc tiếp tục dùng kiến trúc của giai đoạn trước khi áp lực đã đổi.

---

82.24. Dấu hiệu kiến trúc cần tiến hóa

Một số dấu hiệu rõ:

Deploy một tính năng nhỏ làm nhiều phần không liên quan hỏng.
Team không biết module nào sở hữu logic.
Database query chậm lặp lại.
Queue backlog vượt SLO.
Một tenant làm tenant khác chậm.
Cost không giải thích được.
Support không debug được khách hàng.
Incident không có log/trace/audit.
Security requirement không đáp ứng được vì data model sai.

Khi thấy dấu hiệu, đừng phản ứng bằng công nghệ ngay.

Hãy hỏi:

Áp lực thật là gì?
Nó nằm ở domain, data, team, scale, reliability, cost hay compliance?
Thay đổi nhỏ nhất nào giảm áp lực?

Ví dụ:

Queue backlog

không nhất thiết cần microservices.

Có thể cần:

Tăng concurrency hợp lý.
Giới hạn provider.
Tách queue theo job type.
Priority.
Better metrics.

Chẩn đoán trước khi phẫu thuật.

---

82.25. Những sai lầm phổ biến

Sai lầm thứ nhất:

Copy kiến trúc công ty lớn.

Không copy được cả đội ngũ, tooling, traffic và vấn đề của họ.

Sai lầm thứ hai:

Giữ prototype quá lâu.

Code thử nghiệm thành production nhưng thiếu nền.

Sai lầm thứ ba:

MVP cắt luôn correctness.

Không mất dữ liệu, auth, permission, backup cơ bản không nên bị cắt.

Sai lầm thứ tư:

Tách microservices trước khi boundary rõ.

Từ monolith rối thành distributed monolith rối hơn.

Sai lầm thứ năm:

Không trả nợ data model sớm.

Thiếu tenant_id, audit actor, version, source of truth rồi sau này sửa rất đau.

Sai lầm thứ sáu:

Chỉ tối ưu scale, quên vận hành.

Hệ thống chịu tải nhưng không debug/restore/deploy được.

Sai lầm thứ bảy:

Không biết giai đoạn hiện tại.

Lúc thì làm như prototype, lúc thì kỳ vọng enterprise.

---

82.26. Checklist chọn kiến trúc theo giai đoạn

Trước khi quyết định kiến trúc, hãy hỏi:

• Hệ thống đang ở giai đoạn nào: prototype, MVP, khách thật, scale-up, enterprise?
• Mục tiêu chính của giai đoạn này là học, phục vụ, scale hay compliance?
• Dữ liệu production đã có giá trị thật chưa?
• Khách hàng có trả tiền chưa?
• Lỗi nhỏ có gây mất niềm tin lớn không?
• Team có bao nhiêu người vận hành?
• Domain boundary đã rõ chưa?
• Có cần tách service thật không, hay module boundary đủ?
• Bottleneck hiện tại đo được là gì?
• Nợ nào đang cản giai đoạn tiếp theo?
• Tính năng enterprise nào có khách thật yêu cầu?
• Có thứ nào cần làm sớm để không khóa đường sau này không?
• Có thứ nào đang over-engineer trước nhu cầu không?
• Kiến trúc đề xuất có ai trong team vận hành nổi không?
• Nếu traffic gấp 10 lần, điểm nghẽn đầu tiên là gì?
• Nếu khách enterprise ký ngày mai, thiếu gì nghiêm trọng nhất?

Checklist này giúp ta chọn theo bối cảnh.

Không chọn theo mốt.

---

82.27. Bảng nhìn nhanh

| Giai đoạn | Mục tiêu | Kiến trúc nên ưu tiên | |---|---|---| | Prototype | Học nhanh, chứng minh ý tưởng | Cực đơn giản, dễ thay đổi, dễ bỏ | | MVP | User thật dùng được | Luồng chính đúng, dữ liệu không mất, queue/job cơ bản | | Có khách hàng thật | Tin cậy và support được | Audit, monitoring, backup, support tooling, deploy an toàn | | Scale-up | Chịu tải và team lớn hơn | Tách bottleneck, queue priority, cache/read model, cost controls | | Enterprise | Đáp ứng khách lớn/compliance | SSO, audit nâng cao, data residency, isolation, SLA |

---

82.28. Kết luận của chương

Kiến trúc nên đi cùng giai đoạn sản phẩm.

Prototype cần học nhanh.

MVP cần luồng chính đúng và đủ tin cho user thật.

Có khách hàng thật cần observability, backup, audit và support.

Scale-up cần xử lý bottleneck, cost, tenant fairness và vận hành tốt hơn.

Enterprise cần compliance, isolation, audit, SSO, data residency và cam kết rõ.

Đừng dùng kiến trúc công ty lớn cho sản phẩm chưa có người dùng.

Nhưng cũng đừng giữ kiến trúc prototype khi đã có dữ liệu, khách hàng và trách nhiệm thật.

Thông điệp cần nhớ:

> Kiến trúc tốt là kiến trúc đúng thời điểm. Nó đủ đơn giản để team chạy nhanh hôm nay, đủ chắc để không làm hỏng thứ quan trọng, và đủ có đường tiến hóa khi áp lực thật xuất hiện.

Ở chương tiếp theo, ta sẽ gom lại thành checklist thiết kế: request path, data model, consistency, async job, cache, security, observability, deploy, backup, cost và failure modes.