Solution Architect - AI Domain, Cloud, Kubernetes

Quyết định kiến trúc là chọn trade-off dựa trên ràng buộc thực tế (nghiệp vụ, đội ngũ, ngân sách, thời gian), không phải chọn công nghệ "tốt nhất".

• Xác định các thuộc tính chất lượng quan trọng nhất (hiệu năng, sẵn sàng, bảo mật, chi phí, khả năng thay đổi) và sắp xếp ưu tiên cùng stakeholder.
• Đưa ra 2–3 phương án, so sánh rủi ro; làm POC hoặc spike cho điểm chưa chắc chắn.
• Ghi lại bằng ADR (Architecture Decision Record): bối cảnh, quyết định, phương án đã loại, hệ quả. Lưu cùng repo để người sau hiểu "vì sao".
• Phân biệt quyết định khó đảo ngược (chọn DB, ranh giới service) với quyết định dễ thay đổi; quyết định dễ đảo ngược thì nên làm nhanh.
• Xem lại quyết định khi bối cảnh thay đổi.

Người phỏng vấn muốn nghe: bạn thuyết phục đội ngũ bằng dữ liệu, lắng nghe phản biện, và kể được một quyết định từng sai cùng cách bạn sửa.

Microservices giải quyết vấn đề tổ chức: nhiều team cần deploy độc lập và scale riêng từng phần. Nó không tự làm hệ thống nhanh hơn.

Nên cân nhắc tách khi:

• Nhiều team đụng nhau trong cùng codebase, deploy phải chờ nhau.
• Một phần có tải hoặc yêu cầu công nghệ rất khác phần còn lại.
• Ranh giới nghiệp vụ (bounded context) đã rõ ràng và ổn định.

Cái giá: gọi mạng thay vì gọi hàm (độ trễ, lỗi một phần), nhất quán dữ liệu phân tán, cần tracing, service discovery, CI/CD và vận hành phức tạp hơn.

Người phỏng vấn muốn nghe: "modular monolith" là bước khởi đầu hợp lý: chia module rõ ràng trong một ứng dụng, sau này tách theo đúng ranh giới đó. Tách sai ranh giới tạo ra "distributed monolith", tệ hơn cả monolith.

Cache giảm độ trễ và tải cho DB, đổi lại phải chấp nhận dữ liệu có thể cũ trong một khoảng thời gian.

• Cache-aside (phổ biến nhất): đọc cache, miss thì đọc DB rồi ghi vào cache kèm TTL. Khi cập nhật thì ghi DB rồi xoá key cache.
• Write-through: ghi qua cache rồi cache ghi xuống DB, dữ liệu cache luôn mới nhưng ghi chậm hơn.
• Write-behind: ghi cache trước, đẩy xuống DB sau; nhanh nhưng có thể mất dữ liệu.

Các vấn đề cần xử lý:

• Cache stampede: key nóng hết hạn, hàng nghìn request cùng đánh vào DB. Giải pháp: lock hoặc single-flight, làm mới sớm, thêm độ lệch ngẫu nhiên cho TTL.
• Cache penetration: truy vấn key không tồn tại liên tục. Giải pháp: cache cả kết quả rỗng, dùng bloom filter.

Hay sai: cập nhật cache thay vì xoá, dễ ghi đè giá trị cũ khi hai request chạy song song.

Hallucination là khi mô hình sinh ra nội dung nghe hợp lý nhưng sai hoặc không có căn cứ. Không loại bỏ hoàn toàn được, chỉ giảm và kiểm soát.

• Cung cấp ngữ cảnh đúng qua RAG, yêu cầu chỉ trả lời dựa trên nguồn và trích dẫn.
• Cho phép và khuyến khích trả lời "không đủ thông tin".
• Dùng đầu ra có cấu trúc (JSON schema) và kiểm tra hợp lệ bằng code.
• Với số liệu, tra cứu hoặc tính toán qua tool/API thay vì để mô hình tự nhớ.
• Kiểm tra sau sinh: đối chiếu câu trả lời với nguồn.
• Thiết kế UX hiển thị nguồn; tác vụ rủi ro cao có người duyệt.

Người phỏng vấn muốn nghe: đo tỷ lệ hallucination bằng bộ đánh giá, không chỉ dựa vào cảm giác.

Mô hình lên production là một phần mềm cần đóng gói, phiên bản hoá, giám sát và cập nhật như mọi dịch vụ khác.

• Đóng gói: lưu mô hình kèm phiên bản dữ liệu, code, siêu tham số (model registry).
• Phục vụ: API online hoặc chạy batch tuỳ yêu cầu độ trễ; dùng chung code tính đặc trưng giữa train và serve để tránh lệch.
• Triển khai an toàn: shadow hoặc canary, so sánh với mô hình cũ.
• Giám sát: độ trễ, lỗi; data drift (phân phối đầu vào thay đổi); chất lượng dự đoán khi có nhãn thật.
• Cập nhật: train lại định kỳ hoặc khi drift vượt ngưỡng, có rollback.

Hay sai: training-serving skew, xử lý đặc trưng ở hai nơi bằng hai đoạn code khác nhau.

Bắt đầu từ dữ liệu chi phí, không đoán: xem Cost Explorer/Cost Management theo dịch vụ, region, tag và theo ngày để tìm điểm tăng.

Thủ phạm hay gặp:

• Tài nguyên quên tắt: máy dev, ổ đĩa, snapshot, IP tĩnh không gắn máy.
• Data transfer: traffic ra Internet, qua NAT Gateway, giữa AZ/region.
• Log và metric ghi quá nhiều, giữ quá lâu.
• Auto scaling không co lại.

Tối ưu: right-sizing, Savings Plans/Reserved cho tải nền ổn định, spot cho việc chịu ngắt quãng, lifecycle policy chuyển dữ liệu cũ sang lớp lưu trữ rẻ.

Người phỏng vấn muốn nghe: gắn tag bắt buộc và đặt budget alert để phát hiện sớm.

Message queue tách bên gửi và bên nhận: xử lý bất đồng bộ, hấp thụ tải đột biến, cho nhiều hệ thống cùng phản ứng với một sự kiện.

• RabbitMQ: message broker truyền thống, định tuyến linh hoạt qua exchange (direct, topic, fanout), message bị xoá sau khi consumer ack. Hợp với hàng đợi tác vụ như gửi email, xử lý ảnh.
• Kafka: log phân tán chỉ ghi nối, message được giữ theo thời gian cấu hình, consumer tự quản lý offset nên đọc lại được. Thứ tự chỉ đảm bảo trong từng partition. Hợp với event streaming, thông lượng lớn, nhiều consumer group.

Lưu ý khi dùng:

• Mặc định nên coi là at-least-once, nên consumer phải idempotent.
• Có dead letter queue cho message lỗi lặp lại.
• Theo dõi consumer lag.

Người phỏng vấn muốn nghe: lý do chọn gắn với nhu cầu cụ thể, không chọn Kafka chỉ vì nghe "xịn".

CAP nói rằng khi xảy ra phân mảnh mạng (Partition), hệ phân tán phải chọn giữa Consistency (mọi node trả dữ liệu mới nhất hoặc báo lỗi) và Availability (luôn trả lời, có thể bằng dữ liệu cũ). Khi mạng bình thường, trade-off thực tế là giữa độ trễ và tính nhất quán (mô hình PACELC).

• Strong consistency: cần cho số dư tài khoản, tồn kho, đặt chỗ, nơi đọc dữ liệu cũ gây thiệt hại thật.
• Eventual consistency: chấp nhận được cho lượt thích, bảng tin, số người xem, kết quả tìm kiếm.

Một hệ thống thường kết hợp cả hai theo từng loại dữ liệu. Có những mức ở giữa như read-your-writes: người vừa sửa thì phải thấy thay đổi của mình, người khác thấy chậm vài giây cũng không sao.

Hay sai: nói "chọn 2 trong 3" như thể có thể bỏ P. Với hệ phân tán, phân mảnh mạng là chuyện chắc chắn xảy ra.

Rate limiter bảo vệ hệ thống khỏi lạm dụng và quá tải, thường đặt ở API gateway hoặc middleware, đếm theo user, API key hoặc IP.

Thuật toán:

• Fixed window: đơn giản nhưng bị dồn request ở ranh giới hai cửa sổ.
• Sliding window (log hoặc counter): mượt hơn, tốn bộ nhớ hơn.
• Token bucket: cho phép burst ngắn trong giới hạn tốc độ trung bình, được dùng phổ biến.

Khi chạy nhiều instance, bộ đếm phải dùng chung, thường là Redis. Thao tác kiểm tra và tăng phải atomic (INCR kèm EXPIRE, hoặc Lua script).

Trả về HTTP 429 kèm header Retry-After.

Người phỏng vấn muốn nghe: bạn quyết định được khi Redis lỗi thì cho qua (fail-open) hay chặn (fail-closed) và giải thích lý do, đồng thời biết giới hạn riêng cho endpoint đắt như đăng nhập, gửi OTP.

Cho thấy bạn có cách làm cụ thể, không chỉ nói "em chịu được áp lực".

• Chia nhỏ việc, ưu tiên phần quan trọng nhất cho mục tiêu.
• Báo sớm cho lead/PM nếu thấy không kịp, đề xuất cắt phạm vi hoặc xin hỗ trợ.
• Giữ chất lượng ở phần cốt lõi; ghi lại nợ kỹ thuật để xử lý sau.
• Giữ bình tĩnh, giao tiếp ngắn gọn, rõ ràng với team.

Câu mẫu theo STAR: "Trước buổi demo cho khách, team phát hiện lỗi tích hợp chỉ còn hai ngày. Em liệt kê các phần bị ảnh hưởng, cùng PM chọn luồng nào bắt buộc phải chạy cho demo, phần còn lại hẹn bàn giao tuần sau. Demo diễn ra suôn sẻ và khách đồng ý với lịch mới."

Hay sai: khoe thức trắng nhiều đêm. Người phỏng vấn muốn thấy bạn quản lý được áp lực, không chỉ chịu đựng.