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

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.

Bản chất của Database Index

Database Index (thường là B-Tree) là một cấu trúc dữ liệu bổ sung giúp hệ quản trị cơ sở dữ liệu tìm kiếm dữ liệu mà không cần quét toàn bộ bảng (Full Table Scan).

Giao tiếp đồng bộ (Synchronous)

Vấn đề khi để cấu hình trong mã nguồn

Nếu cấu hình (như Database URL, API Key, Secret) được hard-code hoặc để trong file cấu hình đi kèm mã nguồn, bạn sẽ phải build lại toàn bộ ứng dụng mỗi khi thay đổi môi trường (Dev, Staging, Production).

Tầm quan trọng của HTTP Status Codes

HTTP Status Codes cung cấp một ngôn ngữ chung giữa Client và Server. Việc sử dụng sai mã (ví dụ: trả về 200 OK cho mọi trường hợp lỗi) sẽ khiến việc xử lý lỗi ở phía Client trở nên cực kỳ khó khăn.

Khái niệm Dependency Injection

Dependency Injection là một mẫu thiết kế (Design Pattern) nơi một đối tượng không tự khởi tạo các phụ thuộc (dependencies) của nó mà các phụ thuộc này được 'tiêm' vào từ bên ngoài (thường thông qua constructor).

1. Phân biệt Monolithic và Microservices

• Monolithic Architecture: Tất cả các thành phần của ứng dụng (giao diện người dùng, business logic, tầng truy cập dữ liệu) được đóng gói và triển khai thành một khối duy nhất. Ưu điểm là dễ phát triển ban đầu, dễ deploy và debug ở quy mô nhỏ. Nhược điểm là khi hệ thống lớn lên, mã nguồn trở nên cồng kềnh (Monolith hell), khó scale riêng lẻ từng tính năng và một lỗi nhỏ có thể làm sập toàn bộ hệ thống.
• Microservices Architecture: Hệ thống được chia thành các dịch vụ độc lập nhỏ hơn, giao tiếp với nhau qua mạng (thường là REST API, gRPC hoặc Message Broker). Ưu điểm là tính mở rộng cao (scalability), dễ bảo trì từng phần, độc lập công nghệ giữa các service. Nhược điểm là độ phức tạp cao về vận hành, khó khăn trong việc quản lý transaction phân tán (Distributed Transactions) và độ trễ mạng.

2. Định hướng lựa chọn cho Junior

• Đề xuất Monolithic: Khi bắt đầu xây dựng một sản phẩm mới (MVP - Minimum Viable Product), team có quy mô nhỏ (dưới 10 người), chưa rõ về domain business hoặc lượng truy cập dự kiến ban đầu thấp.
• Đề xuất Microservices: Khi hệ thống Monolithic hiện tại đã quá tải, đội ngũ phát triển chia thành nhiều team độc lập làm việc song song, hoặc nghiệp vụ yêu cầu scale cực lớn ở một vài tính năng cụ thể.

3. Kinh nghiệm thực chiến

Không nên áp dụng Microservices ngay từ đầu chỉ vì xu hướng (hype-driven development). Hãy bắt đầu với Modular Monolith để tách biệt rõ ràng các ranh giới module trước khi chuyển đổi sang Microservices khi thực sự cần thiết.

1. Vai trò của API Gateway

API Gateway là điểm vào duy nhất (Single Entry Point) cho tất cả các client (Web, Mobile, Third-party) khi muốn tương tác với hệ thống backend. Nó nằm giữa client và các Microservices phía sau.

1. Các tầng cơ bản trong Layered Architecture

• Presentation Layer (Tầng giao diện): Chịu trách nhiệm hiển thị dữ liệu cho người dùng và nhận yêu cầu từ client (Controllers, UI components, API Endpoints).
• Business Logic Layer / Service Layer (Tầng nghiệp vụ): Chứa các quy tắc nghiệp vụ cốt lõi của ứng dụng (Services, Use Cases).
• Data Access Layer / Persistence Layer (Tầng dữ liệu): Chịu trách nhiệm giao tiếp với cơ sở dữ liệu hoặc các external API (Repositories, ORM, Database queries).

2. Quy tắc dòng chảy phụ thuộc (Dependency Rule)

• Tầng ở phía trên có quyền gọi tầng ở phía dưới trực tiếp.
• TUYỆT ĐỐI KHÔNG để tầng ở phía dưới gọi ngược lại tầng phía trên (trừ khi sử dụng các kỹ thuật đảo ngược phụ thuộc như Dependency Injection hoặc Observer Pattern).
• Quy tắc truyền thống: Presentation phụ thuộc vào Business, Business phụ thuộc vào Data Access. Data Access hoàn toàn độc lập và không biết gì về Presentation.

3. Ví dụ minh họa cấu trúc thư mục chuẩn

com.company.project/
│
├── presentation/
│   └── UserController.java  (Gọi Service)
│
├── business/
│   └── UserService.java     (Gọi Repository)
│
└── data/
    └── UserRepository.java  (Tương tác Database)

4. Kinh nghiệm thực chiến

Hạn chế hiện tượng 'Leaky Abstraction' (Rò rỉ trừu tượng), ví dụ như việc truyền trực tiếp các Entity của tầng Database lên tận tầng Presentation. Nên sử dụng DTO (Data Transfer Object) để chuyển đổi dữ liệu giữa các tầng nhằm giảm sự phụ thuộc.

1. Vai trò của Caching

Caching giúp lưu trữ tạm thời các dữ liệu thường xuyên được truy vấn hoặc tốn nhiều thời gian tính toán vào bộ nhớ truy cập nhanh (như RAM). Điều này giúp giảm tải trực tiếp cho cơ sở dữ liệu chính, giảm độ trễ (Latency) và tăng khả năng chịu tải (Throughput) cho hệ thống.

1. Khái niệm và vai trò của Load Balancer

Load Balancer là một thành phần phần cứng hoặc phần mềm đứng trước một nhóm các máy chủ backend (Server Pool). Nhiệm vụ của nó là tiếp nhận các yêu cầu từ client và phân phối chúng đều tới các máy chủ backend dựa trên các thuật toán định sẵn. Điều này giúp ngăn chặn tình trạng quá tải ở một máy chủ đơn lẻ và đảm bảo tính sẵn sàng cao (High Availability).