Enterprise Architect (Infrastructure, Cloud)

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".

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.

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).

Spring tạo proxy bao quanh bean. Khi gọi method có @Transactional qua proxy, proxy mở transaction, gọi method thật, rồi commit hoặc rollback.

Những lý do hay gặp khiến nó "không ăn":

• Self-invocation: method A trong cùng class gọi this.b() có @Transactional, lời gọi không đi qua proxy.
• Method là private hoặc final: proxy không chặn được lời gọi.
• Mặc định chỉ rollback với unchecked exception và Error. Checked exception vẫn commit, trừ khi khai báo rollbackFor = Exception.class.
• Exception bị catch và nuốt bên trong method.

Nên biết thêm propagation (REQUIRED, REQUIRES_NEW) và readOnly = true cho các truy vấn chỉ đọc.

Người phỏng vấn muốn nghe: bạn giải thích được bằng cơ chế proxy, không chỉ liệt kê lỗi.

Load balancer tầng 4 phân phối theo IP/port (TCP/UDP), không đọc nội dung; tầng 7 hiểu HTTP nên định tuyến được theo path, host, header.

• L7 (ALB, Application Gateway, HTTP(S) LB): định tuyến /api và /web tới các nhóm khác nhau, kết thúc TLS, gắn WAF, hợp web/API.
• L4 (NLB, Azure Load Balancer): độ trễ thấp, thông lượng cao, giao thức không phải HTTP (game, MQTT, DB proxy), cần IP tĩnh.
• Cả hai đều có health check để loại máy hỏng.

Hay sai: health check trỏ vào trang nặng hoặc phụ thuộc DB, khiến LB loại hết máy khi DB chậm.

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.

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.

Chọn một hai điểm mạnh liên quan tới vị trí, và chứng minh bằng ví dụ thật, không liệt kê tính từ.

Cấu trúc: điểm mạnh, ví dụ ngắn, kết quả, liên hệ với công việc mới.

Câu mẫu: "Điểm mạnh của em là chủ động tìm nguyên nhân gốc. Ở dự án trước, hệ thống thỉnh thoảng bị timeout mà không ai tái hiện được. Em tự đọc log, thêm theo dõi ở các điểm nghi ngờ và tìm ra một truy vấn bị khoá bảng vào giờ cao điểm. Sau khi sửa, lỗi đó không còn xuất hiện. Em nghĩ điều này hữu ích với vị trí bên mình vì hệ thống có lượng truy cập lớn."

Hay sai: "Em chăm chỉ, ham học hỏi, chịu được áp lực" mà không có ví dụ. Ai cũng nói vậy nên không đọng lại gì.