Java Fullstack Developer (React/ Elasticsearch /AWS)

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.

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.

Khác nhau ở chỗ bạn tự quản lý tới tầng nào: IaaS bạn lo từ hệ điều hành trở lên, PaaS bạn chỉ lo code và dữ liệu, SaaS bạn chỉ dùng phần mềm.

• IaaS: máy ảo EC2, Azure Virtual Machines, Compute Engine.
• PaaS: Elastic Beanstalk, Azure App Service, Cloud Run, các DB quản lý sẵn như RDS, Cloud SQL.
• SaaS: email, bộ văn phòng, CRM dùng qua trình duyệt.

Người phỏng vấn muốn nghe: mô hình trách nhiệm chung (shared responsibility). Nhà cung cấp lo hạ tầng vật lý; cấu hình bảo mật, quyền truy cập và dữ liệu vẫn là việc của bạn ở mọi mô hình.

Đây là bài toán lost update. Có hai hướng chính, chọn theo mức độ tranh chấp:

• Optimistic locking: thêm field @Version. Khi update, Hibernate kèm điều kiện where version = ?; nếu người khác đã sửa trước, bạn nhận OptimisticLockException và có thể retry hoặc báo lỗi. Hợp khi tranh chấp ít.
• Pessimistic locking: @Lock(LockModeType.PESSIMISTIC_WRITE) sinh SELECT ... FOR UPDATE, giữ khoá đến hết transaction. Hợp khi tranh chấp nhiều, đổi lại throughput giảm và có nguy cơ deadlock.
• Đơn giản nhất cho tồn kho: update có điều kiện ngay trong DB:

UPDATE product SET stock = stock - 1
WHERE id = ? AND stock > 0;

Kiểm tra số dòng bị ảnh hưởng: bằng 0 nghĩa là hết hàng.

Hay sai: dùng synchronized trong code Java. Nó vô dụng khi chạy nhiều instance, và cũng không bảo vệ được dữ liệu ở DB.

== so sánh tham chiếu (hai biến có trỏ cùng một object không), còn equals() so sánh nội dung theo logic bạn định nghĩa.

• Hợp đồng: hai object equals nhau thì bắt buộc có cùng hashCode.
• HashMap/HashSet dùng hashCode để chọn bucket trước, rồi mới dùng equals để so trong bucket. Nếu chỉ override equals, hai object "bằng nhau" có thể rơi vào hai bucket khác nhau, nên set.contains(x) trả về false dù đã add.
• Với Java 16+, record tự sinh equals/hashCode/toString theo các field.

Hay sai: so sánh String hoặc Integer bằng ==. Nó có thể chạy đúng nhờ string pool hoặc cache Integer từ -128 đến 127, rồi sai với giá trị khác.

var có phạm vi hàm, còn let/const có phạm vi block ({}). const không cho gán lại biến, nhưng object hay array bên trong vẫn sửa được.

• Hoisting: khai báo được "kéo" lên đầu phạm vi. var được khởi tạo sẵn là undefined, nên dùng trước khi khai báo không báo lỗi.
• let/const cũng được hoist nhưng chưa khởi tạo. Truy cập trước dòng khai báo ném ReferenceError; khoảng đó gọi là temporal dead zone.
• Function declaration được hoist cả phần thân, nên gọi được trước khi định nghĩa.

console.log(a); // undefined
console.log(b); // ReferenceError
var a = 1;
let b = 2;

Người phỏng vấn muốn nghe: mặc định dùng const, cần gán lại mới dùng let, và gần như không dùng var trong code mới.

Region là một vùng địa lý; mỗi region có nhiều Availability Zone, là các trung tâm dữ liệu tách biệt về điện, mạng, làm mát nhưng nối với nhau độ trễ thấp.

Để chịu được mất một AZ:

• Chạy ứng dụng ở ít nhất 2 AZ, đứng sau load balancer.
• Dùng Auto Scaling group/managed instance group trải trên nhiều AZ.
• Database bật chế độ Multi-AZ (bản standby ở AZ khác, failover tự động).
• Ứng dụng stateless, session để ở Redis hoặc DB.

Hay sai: đặt NAT Gateway hoặc một thành phần duy nhất ở một AZ, tạo điểm lỗi đơn mà không để ý.

VPC là mạng riêng ảo của bạn trên cloud; subnet chia nhỏ dải IP; tính "public" hay "private" của subnet do route table quyết định.

• Public subnet: route 0.0.0.0/0 tới Internet Gateway; đặt load balancer, bastion.
• Private subnet: không có route trực tiếp ra Internet; đặt app server, database.
• NAT Gateway: nằm ở public subnet, cho máy trong private subnet đi ra Internet (tải package, gọi API) nhưng không cho kết nối từ ngoài vào.
• Security group lọc ở mức instance (stateful); Network ACL lọc ở mức subnet (stateless).

Người phỏng vấn muốn nghe: database không bao giờ đặt ở public subnet, và truy cập quản trị nên đi qua bastion hoặc dịch vụ kiểu Session Manager.

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.

Chọn sai lầm thật, có hậu quả vừa phải, nhận trách nhiệm rõ ràng, và nhấn mạnh việc bạn đã thay đổi sau đó.

Cấu trúc: chuyện gì xảy ra, phần lỗi của bạn, bạn khắc phục ngay thế nào, bài học và thay đổi lâu dài.

Câu mẫu: "Có lần em deploy một thay đổi cấu hình lên production vào chiều thứ Sáu mà không kiểm tra kỹ trên staging, làm một tính năng lỗi khoảng một giờ. Em báo ngay cho lead, rollback và viết báo cáo sự cố. Sau đó em đề xuất checklist trước deploy và quy ước hạn chế deploy cuối tuần; team áp dụng tới giờ."

Hay sai: kể một "thất bại" thực ra là khoe, đổ lỗi cho người khác, hoặc nói mình chưa từng thất bại.