CG Kiến trúc sư Giải pháp (Senior Solution Architect)

Trình bày theo luồng request và nói rõ điểm lỗi đơn được loại bỏ ở đâu.

• Biên: DNS, CDN cho nội dung tĩnh, WAF.
• Ứng dụng: load balancer L7 trước nhóm container/VM stateless trải nhiều AZ, auto scaling theo CPU hoặc số request.
• Dữ liệu: DB quản lý sẵn Multi-AZ, read replica cho đọc nhiều, Redis làm cache và session.
• Bất đồng bộ: queue cho việc nặng (gửi mail, xử lý ảnh).
• Vận hành: IaC, backup tự động có thử khôi phục, giám sát và alert theo SLO.

Người phỏng vấn muốn nghe: đánh đổi chi phí. 99.9% thường đủ với một region nhiều AZ; multi-region đắt và phức tạp hơn nhiều.

RPO là lượng dữ liệu tối đa chấp nhận mất (tính theo thời gian); RTO là thời gian tối đa để khôi phục dịch vụ. Hai con số này do nghiệp vụ quyết định và định giá chiến lược.

Từ rẻ đến đắt:

• Backup & restore: sao lưu sang region khác, dựng lại khi cần; RTO hàng giờ.
• Pilot light: dữ liệu được replicate liên tục, chỉ phần lõi chạy sẵn.
• Warm standby: bản thu nhỏ chạy sẵn ở region khác, scale lên khi failover.
• Active-active: nhiều region cùng phục vụ; RTO/RPO gần 0, phức tạp nhất.

Hay sai: có backup nhưng chưa bao giờ thử khôi phục. Kế hoạch DR phải được diễn tập định kỳ.

Dùng mô hình landing zone: tách account (AWS), subscription (Azure) hoặc project (GCP) theo môi trường và team để cô lập quyền, chi phí và phạm vi sự cố.

• Quản lý tập trung bằng AWS Organizations, Azure Management Groups, GCP Organization/Folder.
• Áp guardrail ở cấp tổ chức: chặn region không dùng, bắt buộc mã hoá, cấm tắt log audit (SCP, Azure Policy, Organization Policy).
• Đăng nhập tập trung qua SSO, cấp quyền theo nhóm.
• Tài khoản riêng cho log audit và bảo mật, team ứng dụng không xoá được.
• Mạng nối qua hub (Transit Gateway, hub-spoke VNet, Shared VPC).
• Tag bắt buộc để phân bổ chi phí.

Người phỏng vấn muốn nghe: cân bằng giữa tự chủ của team và kiểm soát tập trung.

Cô lập lỗi để sự cố của một phụ thuộc không lan ra toàn hệ thống (cascading failure).

• Timeout cho mọi lời gọi mạng. Thiếu timeout là nguyên nhân hàng đầu làm cạn thread hoặc connection.
• Retry có giới hạn, exponential backoff kèm jitter, và chỉ retry thao tác idempotent.
• Circuit breaker: lỗi vượt ngưỡng thì "ngắt mạch", trả lỗi nhanh trong một thời gian, sau đó thử lại dần (half-open).
• Bulkhead: tách pool thread hoặc connection theo từng phụ thuộc.
• Fallback / graceful degradation: trả dữ liệu cache, ẩn tính năng phụ thay vì lỗi cả trang.
• Load shedding: từ chối bớt request khi quá tải để bảo vệ phần còn lại.

Hay sai: retry ở nhiều tầng cùng lúc, số request nhân lên theo cấp số và làm phụ thuộc đang yếu chết hẳn (retry storm).

Tránh two-phase commit giữa các service; thay vào đó dùng Saga kết hợp Outbox pattern.

• Saga: chuỗi transaction cục bộ, mỗi bước có hành động bù trừ nếu bước sau thất bại (vd. đặt hàng → giữ tồn kho → thanh toán; thanh toán lỗi thì hoàn tồn kho, huỷ đơn). Có hai kiểu: choreography (các service phản ứng theo event) và orchestration (một service điều phối, dễ theo dõi hơn khi luồng dài).
• Transactional outbox: ghi thay đổi nghiệp vụ và event vào bảng outbox trong cùng một transaction DB, sau đó tiến trình riêng hoặc CDC đẩy event lên broker. Cách này tránh tình huống DB đã lưu mà event bị mất.
• Consumer phải idempotent (lưu id message đã xử lý) vì event có thể đến nhiều lần.

Người phỏng vấn muốn nghe: bạn chấp nhận eventual consistency và thiết kế trạng thái trung gian rõ ràng cho người dùng, vd. đơn ở trạng thái "đang xử lý".

Multi-cloud có lý do chính đáng nhưng chi phí vận hành rất lớn; cần hỏi rõ mục tiêu trước khi đồng ý.

Lý do hợp lý:

• Yêu cầu pháp lý hoặc khách hàng chỉ định nhà cung cấp.
• Dùng dịch vụ đặc thù tốt nhất của từng bên.
• Công ty sáp nhập, mỗi bên đã dùng một cloud.

Cái giá:

• Đội phải giỏi hai nền tảng, IAM và mạng khác nhau.
• Chi phí truyền dữ liệu giữa cloud.
• Chỉ dùng mẫu số chung, mất lợi thế dịch vụ managed.

Giảm phụ thuộc thường chỉ cần container, Terraform và tránh API độc quyền ở phần lõi.

Người phỏng vấn muốn nghe: biết hỏi "để giải quyết vấn đề gì", không trả lời có/không ngay.

User đại diện cho một người hoặc ứng dụng với credential dài hạn; role là tập quyền được "đội" tạm thời và cấp credential ngắn hạn tự hết hạn.

• Ứng dụng chạy trên cloud nên dùng role gắn vào máy ảo, container, function (instance profile, managed identity, service account).
• CI/CD ngoài cloud dùng OIDC federation để lấy token ngắn hạn, không cần key cố định.
• Áp dụng least privilege: chỉ cấp đúng action trên đúng resource.
• Bật MFA cho người dùng, hạn chế dùng tài khoản root.

Access key trong code dễ lộ qua Git, log, image; một khi lộ thì dùng được tới khi bị thu hồi.

Người phỏng vấn muốn nghe: policy cụ thể, tránh "Action": "*".

Serverless hợp với tải không đều, xử lý theo sự kiện, đội nhỏ không muốn vận hành server; trả tiền theo lượng dùng.

Hợp:

• Xử lý file khi upload, webhook, cron job, API lưu lượng thấp hoặc thất thường.

Cân nhắc:

• Cold start làm tăng độ trễ request đầu.
• Giới hạn thời gian chạy, bộ nhớ, kích thước gói.
• Tải cao và đều thì container/VM thường rẻ hơn.
• Kết nối DB: nhiều instance mở nhiều connection, cần connection pooler hoặc proxy.
• Khó debug và test cục bộ hơn.

Người phỏng vấn muốn nghe: quyết định dựa trên đặc điểm tải và chi phí, không chọn vì "đang hot".

Tách phần nhận yêu cầu khỏi phần gửi qua hàng đợi, và tách riêng từng kênh để kênh này lỗi không ảnh hưởng kênh khác.

• Notification service nhận yêu cầu, kiểm tra cài đặt và tuỳ chọn tắt thông báo của người dùng, render template, rồi đẩy vào queue theo kênh.
• Worker theo kênh gọi nhà cung cấp (FCM/APNs, email, SMS), retry có backoff, chuyển message lỗi vĩnh viễn sang dead letter queue.
• Ưu tiên: OTP, giao dịch dùng queue riêng, không bị kẹt sau chiến dịch marketing gửi hàng loạt.
• Chống trùng: idempotency key cho mỗi thông báo.
• Giới hạn: rate limit theo nhà cung cấp và theo người dùng; tôn trọng khung giờ yên lặng.
• Lưu trạng thái gửi, mở, lỗi để theo dõi và xử lý token thiết bị hết hạn.

Người phỏng vấn muốn nghe: bạn ước lượng được lưu lượng lúc cao điểm và nêu cách scale worker theo độ dài hàng đợi.

Trả lời thẳng thắn và cân bằng: sẵn sàng khi thật sự cần, nhưng không coi OT kéo dài là bình thường.

Câu mẫu: "Em sẵn sàng làm thêm khi có việc gấp như sự cố production hay trước một đợt release quan trọng. Nhưng nếu OT diễn ra thường xuyên, em nghĩ cần xem lại cách estimate hoặc phạm vi, và em sẽ chủ động nêu điều đó với team. Em cũng muốn hỏi thêm: ở team mình OT thường xảy ra trong trường hợp nào và được tính như thế nào ạ?"

Đây cũng là lúc bạn tìm hiểu ngược: OT có được trả lương hoặc nghỉ bù theo quy định không, tần suất ra sao. Câu trả lời của họ cho bạn biết nhiều về văn hoá công ty.

Hay sai: hứa "OT thoải mái" để lấy điểm, rồi vào làm mới thấy không chịu nổi.