Backend Engineer (Java, Golang, Cloud, AWS, PostgreSQL)

Object storage lưu file dạng đối tượng truy cập qua HTTP API, dung lượng gần như không giới hạn và rẻ; block storage là ổ đĩa gắn vào máy ảo; file storage là ổ mạng dùng chung qua NFS/SMB.

• Object: ảnh, video, backup, data lake, static website. Không sửa một phần file được, phải ghi đè cả object.
• Block (EBS, Managed Disk, Persistent Disk): ổ hệ điều hành, database tự quản; độ trễ thấp.
• File (EFS, Azure Files, Filestore): nhiều máy cùng đọc ghi một thư mục.

Hay sai: để bucket public để tiện chia sẻ. Nên giữ bucket private, chia sẻ bằng presigned URL hoặc CDN có kiểm soát.

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

IoC container của Spring tạo và quản lý các bean, rồi "tiêm" phụ thuộc vào class cần dùng, thay vì class tự new. Nhờ vậy code ít phụ thuộc cứng, dễ thay implementation và dễ test.

Constructor injection được khuyên dùng vì:

• Field có thể là final, object luôn ở trạng thái đầy đủ sau khi tạo.
• Test unit không cần Spring: chỉ cần new OrderService(mockRepo).
• Constructor quá nhiều tham số là dấu hiệu class đang ôm nhiều việc.
• Class chỉ có một constructor thì không cần ghi @Autowired.

Nên nói thêm về scope: mặc định bean là singleton (một instance cho cả context), ngoài ra có prototype, request, session.

Hay sai: để state thay đổi được (ví dụ biến đếm, list) trong bean singleton. Nhiều request chạy song song sẽ dùng chung và gây race condition.

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.

Không. Đọc và ghi map đồng thời có thể làm runtime dừng chương trình với lỗi "concurrent map read and map write". Các biến dùng chung khác cũng có data race nhưng thường im lặng cho kết quả sai.

Phát hiện bằng race detector: go test -race ./... hoặc go run -race. Nên bật trong CI.

Cách xử lý:

• sync.Mutex bọc map, hoặc sync.RWMutex khi đọc nhiều hơn ghi rất nhiều.
• sync.Map hợp với vài trường hợp đặc thù (key ghi một lần đọc nhiều lần, hoặc mỗi goroutine dùng tập key riêng); không phải thay thế mặc định.
• Bộ đếm đơn giản: atomic.Int64.
• Hoặc tránh chia sẻ: để một goroutine sở hữu dữ liệu, các goroutine khác gửi yêu cầu qua channel.

Hay sai: copy struct có chứa sync.Mutex (truyền theo giá trị), khiến mỗi bản có một khoá riêng. go vet cảnh báo được lỗi này.

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.

Người phỏng vấn muốn biết bạn tự quản lý được và giao tiếp chủ động khi không ngồi cạnh team.

• Cập nhật tiến độ thường xuyên trên công cụ chung (ticket, kênh chat của team), không để người khác phải hỏi.
• Viết rõ ràng: câu hỏi có ngữ cảnh, ghi lại kết quả thảo luận.
• Có khung giờ làm việc ổn định, phản hồi trong giờ làm, báo trước khi vắng.
• Dùng ngày lên văn phòng (nếu hybrid) cho thảo luận, brainstorm, gặp gỡ team.

Câu mẫu: "Team cũ của em làm hybrid hai ngày ở văn phòng. Những ngày remote em cập nhật trạng thái task mỗi sáng và cuối ngày, vướng gì thì gọi nhanh 10 phút thay vì nhắn qua lại."