Thư Viện Câu Hỏi Phỏng Vấn

Khi phát triển phần mềm theo tiêu chuẩn Enterprise, việc kiểm thử từng thành phần riêng lẻ (Unit Testing) đòi hỏi lập trình viên phải cô lập đối tượng cần kiểm thử khỏi các phụ thuộc bên ngoài như Database, Third-party API hoặc File System.

Khi xây dựng các kịch bản kiểm thử, lập trình viên thường gặp tình huống phải kiểm tra một hàm logic với nhiều tập dữ liệu đầu vào và kết quả kỳ vọng khác nhau. Thay vì viết lặp lại nhiều hàm test có cấu trúc giống nhau, Parameterized Testing là giải pháp tối ưu.

Kiểm thử tích hợp (Integration Testing) ở tầng API đóng vai trò xác thực rằng các tầng Controller, Service và Database tương tác chính xác với nhau, không chỉ dựa vào các đối tượng giả lập (Mock).

Các ứng dụng hiện đại sử dụng rất nhiều lập trình bất đồng bộ (Asynchronous Programming). Nếu lập trình viên không xử lý đúng cách trong mã nguồn kiểm thử, test runner sẽ kết thúc trước khi kết quả trả về, dẫn đến hiện tượng Test Pass giả (False Positive).

Code Coverage là một chỉ số định lượng giúp đội ngũ phát triển biết được phần nào của mã nguồn đã được thực thi thông qua bộ kiểm thử tự động (Unit và Integration Tests).

Khái niệm API Rate Limiting

API Rate Limiting là kỹ thuật kiểm soát số lượng yêu cầu (requests) mà một client có thể gửi đến server trong một khoảng thời gian nhất định. Nếu vượt quá ngưỡng này, server sẽ từ chối yêu cầu và trả về lỗi 429 Too Many Requests.

Tầm quan trọng của Multi-stage builds

1. Tối ưu kích thước Image: Bằng cách tách biệt môi trường build (chứa compiler, dependencies) và môi trường runtime (chỉ chứa file thực thi), dung lượng image cuối cùng sẽ giảm đáng kể.
2. Bảo mật: Việc loại bỏ các công cụ build, source code gốc và các file cấu hình nhạy cảm khỏi image cuối cùng giúp giảm thiểu bề mặt tấn công (attack surface).

Ví dụ thực chiến

# Stage 1: Build
FROM node:18 AS builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

# Stage 2: Runtime
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

Việc sử dụng cách tiếp cận này giúp image cuối cùng chỉ chứa các file tĩnh đã build, không chứa mã nguồn gốc, giúp hệ thống nhẹ hơn và an toàn hơn.

Khái niệm Service Discovery

Service Discovery là cơ chế tự động giúp các dịch vụ tìm thấy địa chỉ IP và port của nhau mà không cần cấu hình cứng (hard-coding) địa chỉ IP. Hệ thống bao gồm một Service Registry (như Consul, Eureka hoặc Kubernetes DNS).

Phân biệt Logging và Tracing

• Logging: Ghi lại các sự kiện rời rạc xảy ra trong một service (ví dụ: 'User logged in', 'Database connection failed').
• Tracing: Theo dõi hành trình của một request đi qua nhiều dịch vụ khác nhau trong hệ thống (Distributed Tracing).

Tại sao Logging là không đủ?

Trong kiến trúc Microservices, một nghiệp vụ có thể đi qua 5-10 dịch vụ khác nhau. Nếu chỉ nhìn vào log của từng service, bạn không thể biết request đó đã bị tắc nghẽn hoặc lỗi ở đâu trong chuỗi gọi. Tracing sử dụng một Correlation ID để gắn kết tất cả các log liên quan đến một request duy nhất, giúp lập trình viên nhìn thấy toàn cảnh bức tranh giao tiếp giữa các dịch vụ.

Khái niệm

• Hard Delete: Xóa hoàn toàn bản ghi khỏi bảng bằng lệnh DELETE.
• Soft Delete: Sử dụng một trường dữ liệu (ví dụ: is_deleted hoặc deleted_at) để đánh dấu bản ghi đã bị xóa mà không thực sự xóa dữ liệu khỏi database.

Lợi ích của Soft Delete

1. Khả năng phục hồi dữ liệu: Cho phép quản trị viên khôi phục lại dữ liệu nếu người dùng xóa nhầm.
2. Đảm bảo tính toàn vẹn dữ liệu (Data Integrity): Tránh việc làm hỏng các mối quan hệ khóa ngoại (Foreign Key) trong các bảng liên quan.
3. Phân tích dữ liệu: Giữ lại dữ liệu lịch sử giúp các đội ngũ Business Intelligence (BI) phân tích xu hướng hành vi của người dùng ngay cả khi họ đã hủy tài khoản.

Lưu ý thực chiến

Khi sử dụng Soft Delete, mọi câu truy vấn SELECT phải luôn đi kèm điều kiện WHERE deleted_at IS NULL. Điều này đòi hỏi lập trình viên phải cẩn thận trong việc viết câu lệnh truy vấn hoặc sử dụng các Global Scope trong ORM để tự động thêm điều kiện này.

Khái niệm Circuit Breaker Pattern

Circuit Breaker là một mẫu thiết kế phần mềm (Design Pattern) dùng để phát hiện lỗi và gói gọn logic ngăn chặn việc liên tục gọi đến một dịch vụ (Service) đang gặp sự cố hoặc quá tải, giúp hệ thống phục hồi nhanh chóng.

Khái niệm Health Check

Health Check là các điểm cuối (endpoints) HTTP hoặc lệnh kiểm tra nội bộ mà orchestration tools (như Kubernetes) sử dụng để đánh giá trạng thái hiện tại của một container.

Vấn đề của Retry thông thường

Khi gọi API bên thứ ba bị lỗi (ví dụ lỗi mạng tạm thời), việc gọi lại ngay lập tức (Immediate Retry) có thể làm trầm trọng thêm tình trạng quá tải của hệ thống đích (Thundering Herd Problem).

Khái niệm Distributed Lock

Distributed Lock là cơ chế khóa phân tán giúp đảm bảo rằng chỉ có một tiến trình (hoặc một instance service) duy nhất được phép truy cập vào một tài nguyên chia sẻ tại một thời điểm trong hệ thống gồm nhiều nodes chạy song song.

Khái niệm Graceful Shutdown

Graceful Shutdown là quá trình ứng dụng dừng hoạt động một cách có kiểm soát khi nhận được tín hiệu kết thúc (ví dụ: SIGTERM từ Kubernetes hoặc Docker). Thay vì ngắt kết thúc ngay lập tức (Abrupt Termination), ứng dụng sẽ thực hiện các bước sau: