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

Bản chất vấn đề

Khi xây dựng API phục vụ tính toán số Fibonacci, nếu client liên tục gửi request với cùng một giá trị N lớn, server sẽ tốn tài nguyên CPU để tính toán lại liên tục. Việc áp dụng Caching tại tầng Application là bắt buộc để tối ưu Response Time.

Bản chất của Salt trong Hashing

Salt là một chuỗi dữ liệu ngẫu nhiên được thêm vào mật khẩu trước khi thực hiện quá trình Hashing.

Phân biệt Digital Signature và Encryption

• Encryption (Mã hóa): Mục tiêu là bảo mật dữ liệu (Confidentiality). Chỉ người có khóa giải mã mới đọc được nội dung.
• Digital Signature (Chữ ký số): Mục tiêu là xác thực nguồn gốc (Authentication) và toàn vẹn dữ liệu (Integrity). Nó đảm bảo rằng dữ liệu không bị thay đổi và được gửi bởi đúng người sở hữu khóa bí mật.

Ứng dụng trong Microservices

Trong kiến trúc Microservices, Digital Signature thường được sử dụng để xác thực các yêu cầu (Request) giữa các Service thông qua JWT (JSON Web Token).

Tầm quan trọng của Key Management

Trong Cryptography, thuật toán mã hóa (như AES-256) thường được coi là tiêu chuẩn công nghiệp và rất khó để phá vỡ. Điểm yếu lớn nhất của hệ thống thường nằm ở cách quản lý khóa (Key Management).

HTTPS và bảo mật truyền tải

HTTPS là sự kết hợp giữa giao thức HTTP và lớp bảo mật SSL/TLS. Nó giải quyết ba vấn đề chính:

Tấn công Man-in-the-Middle (MITM)

MITM là hình thức tấn công mà kẻ tấn công đứng giữa Client và Server, chặn và sửa đổi thông tin truyền tải mà cả hai bên đều không hay biết.

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

Bản chất cơ chế

• Cache-Aside (Lazy Loading): Ứng dụng sẽ tương tác trực tiếp với Cache trước. Nếu dữ liệu không tồn tại trên Cache (Cache Miss), ứng dụng sẽ truy vấn vào Database, lấy dữ liệu về, sau đó ghi ngược lại vào Cache để phục vụ cho các lần gọi tiếp theo.
• Write-Through Caching: Khi có dữ liệu mới cần cập nhật, ứng dụng sẽ ghi dữ liệu đó đồng thời vào cả Cache và Database trong cùng một giao dịch (transaction) hoặc thông qua một tầng trung gian.

So sánh và Tình huống áp dụng thực tế

• Cache-Aside:

Định nghĩa

Bản chất vấn đề

Redis lưu trữ dữ liệu hoàn toàn trên RAM (In-memory database). Nếu không giới hạn dung lượng bộ nhớ tối đa thông qua thuộc tính maxmemory, Redis sẽ tiêu thụ toàn bộ RAM vật lý của máy chủ khi lượng dữ liệu phình to, dẫn đến việc hệ điều hành kích hoạt cơ chế OOM Killer (Out Of Memory) và tiến trình Redis bị crash đột ngột.

Vấn đề Race Condition trong Caching

Khi có hai luồng (Thread A và Thread B) cùng thực hiện cập nhật dữ liệu cho một bản ghi: