Bản hướng dẫn đối thoại nội bộ

CTO (Nguyễn Minh): Hệ thống SaaS hiện tại sử dụng nền tảng đóng của nhà cung cấp nước ngoài. Sau hai năm, chi phí license tăng 40% và API không mở được cho đối tác tại Việt Nam. Chúng ta cần chuyển sang kiến trúc mở hay tiếp tục chịu chi phí?

Kiến trúc sư (Trần Hùng): Việc chuyển đổi là cần thiết nếu mục tiêu là giảm sự phụ thuộc vào nhà cung cấp và cho phép mở rộng API. Tuy nhiên, phải tính toán chi phí di chuyển dữ liệu và vận hành thực tế, không chỉ dựa trên lý thuyết.

API Governance

CTO: API hiện tại bị giới hạn bởi tài liệu nội bộ của nhà cung cấp. Muốn expose cho đối tác local thì phải qua họ, dẫn đến chậm trễ và mất kiểm soát version.

Kiến trúc sư: Áp dụng thiết kế API-first với OpenAPI Specification 3.0. Tách biệt hoàn toàn frontend (React/Next.js) và backend services. Sử dụng schema registry để quản lý version contract giữa các service. Điều này loại bỏ phụ thuộc vào tài liệu đóng.

Tiêu chí	Giải pháp đóng	Open architecture (OpenAPI + Schema Registry)
Version API	Phụ thuộc vendor	Quản lý độc lập qua registry
Tài liệu	Nội bộ, không export	OpenAPI 3.0, tự generate client
Mở rộng cho đối tác local	Yêu cầu phê duyệt vendor	Self-service qua contract

CTO: Rủi ro là vendor lock-in hiện tại đã ăn sâu vào dữ liệu và luồng xác thực.

Kiến trúc sư: Thay SSO độc quyền bằng OAuth2 + OIDC kết hợp mTLS giữa các service. Frontend gọi backend qua gateway, không còn phụ thuộc session của vendor.

Data Portability

CTO: Dữ liệu nằm trong hệ thống đóng. Di chuyển sang PostgreSQL kết hợp TimescaleDB sẽ tốn chi phí và thời gian. Làm sao đảm bảo không mất tính toàn vẹn?

Kiến trúc sư: Sử dụng event-driven architecture với Apache Kafka hoặc NATS để tách luồng dữ liệu. Dữ liệu được xuất theo event thay vì dump trực tiếp. TimescaleDB xử lý time-series mà không cần vendor-specific extension. Chi phí migration chủ yếu là nhân sự và testing, không phải license.

Tiêu chí	Giải pháp đóng	PostgreSQL + TimescaleDB + Kafka/NATS
Di chuyển dữ liệu	Phụ thuộc công cụ vendor	Export event-based, kiểm soát được
Mở rộng storage	Tăng license	Horizontal scaling qua Kubernetes
Query time-series	Giới hạn bởi vendor	Native với TimescaleDB

CTO: Bảo mật giữa các service sau khi tách?

Kiến trúc sư: mTLS cho service-to-service, OAuth2 + OIDC cho client. Không dùng SSO vendor nữa.

Observability

CTO: Hệ thống đóng có dashboard riêng. Sau khi chuyển sang Kubernetes và nhiều service nhỏ, làm sao monitor được?

Kiến trúc sư: Triển khai OpenTelemetry cho tracing, metrics và logs. Kết hợp với Prometheus + Grafana hoặc backend tương đương. Event-driven qua Kafka giúp trace request xuyên service mà không cần vendor agent.

CTO: Chi phí vận hành sẽ tăng ban đầu do cần đội ngũ quản lý Kubernetes.

Kiến trúc sư: Đúng. Nhưng chi phí license giảm dần sau 18–24 tháng nếu scale được.

CTO: Vậy quyết định là chuyển. Điều kiện tiên quyết: phải có ít nhất hai người có kinh nghiệm Kubernetes và data migration, ngân sách cho 6 tháng song song hai hệ thống, và test đầy đủ API contract với đối tác local trước khi cutover.

Kiến trúc sư: Đồng ý. Không chuyển nếu không đáp ứng được ba điều kiện trên.

Đây là tình huống giả định nhằm cung cấp khung phân tích kỹ thuật. Người đọc tự đánh giá áp dụng cho trường hợp thực tế của mình.