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

Bản chất vấn đề

Khi một client gửi request tới Load Balancer, Load Balancer sẽ đóng vai trò là một Reverse Proxy. Nó sẽ thiết lập một kết nối TCP riêng biệt với Backend Server. Do đó, khi packet đến Backend Server, địa chỉ nguồn (Source IP) trong gói tin TCP sẽ là địa chỉ của Load Balancer chứ không phải là địa chỉ IP thực sự của client.

Hiện tượng lỗi

Khi quản trị viên tiến hành dừng một Backend Server để cập nhật phiên bản mới, nếu Load Balancer lập tức cắt đứt kết nối hoặc ngừng định tuyến, các request đang được xử lý dở dang (ví dụ: giao dịch thanh toán, upload file lớn) sẽ bị hủy ngang lập tức, dẫn đến lỗi 502 Bad Gateway hoặc lỗi kết nối cho người dùng cuối.

Bản chất vấn đề

Service Decomposition là quá trình chia nhỏ một ứng dụng Monolithic thành các Microservices độc lập. Nếu không phân chia đúng ranh giới nghiệp vụ (Business Domain), hệ thống sẽ rơi vào trạng thái Distributed Monolith, nơi các service phụ thuộc lẫn nhau quá mức, gây suy giảm hiệu năng và khó bảo trì.

Bản chất vấn đề

Trong môi trường Cloud-Native, các Microservices chạy bên trong các Container và được quản lý tự động bởi các Orchestrator như Kubernetes. Hệ thống cần biết chính xác khi nào một service sẵn sàng nhận traffic và khi nào nó bị lỗi nghiêm trọng để tiến hành khởi động lại (Restart) hoặc cách ly (Isolate).

Bản chất vấn đề

Trong mạng máy tính phân tán, các lỗi mạng (network timeout, packet loss) là điều không thể tránh khỏi. Khi một Client gửi request thanh toán đến Microservices nhưng bị timeout ở tầng mạng, Client sẽ có xu hướng retry lại request đó. Nếu API không có cơ chế Idempotency, hệ thống sẽ thực hiện giao dịch trừ tiền nhiều lần.

Bản chất vấn đề

Một hệ thống Microservices có thể bao gồm hàng chục hoặc hàng trăm service khác nhau. Nếu mỗi service tự quản lý file cấu hình riêng (như application.yml, .env), việc thay đổi một tham số chung (như chuỗi kết nối Database, cấu hình Redis, hay thời gian timeout) đòi hỏi phải sửa code, build lại Docker image và deploy lại toàn bộ các service đó, gây mất rất nhiều thời gian và rủi ro cao.

Bản chất vấn đề

Trong hệ thống Microservices, các service phát triển và được deploy độc lập bởi nhiều team khác nhau. Khi một service thay đổi cấu trúc dữ liệu trả về (Data Contract) mà không tương thích ngược (Backward Compatible), các service gọi nó (consumers) hoặc Frontend/Mobile apps sẽ lập tức bị lỗi.

1. Bản chất cơ chế hoạt động của CORS (Cross-Origin Resource Sharing)

CORS là một cơ chế bảo mật cốt lõi được thực thi bởi các trình duyệt web hiện đại, dựa trên chính sách Same-Origin Policy (SOP). Chính sách này ngăn chặn các kịch bản chạy trên một Origin (kết hợp giữa Protocol, Domain, và Port) này có thể đọc tài nguyên từ một Origin khác.

Bản chất vấn đề

Trong ngành phát triển phần mềm, có một nguyên tắc vàng trong bảo mật được phát biểu bởi Kerckhoffs: "Hệ thống phải được bảo mật ngay cả khi mọi chi tiết về hệ thống, trừ khóa, đều là công khai". Một lỗi phổ biến mà các lập trình viên cấp độ Junior thường mắc phải là tự viết ra các hàm mã hóa riêng (Custom Cryptography) dựa trên việc xáo trộn chuỗi, dịch bit, XOR với một chuỗi cố định, hoặc tự kết hợp các hàm băm cơ bản.

Việc đặt Business Logic vào Middleware là một Anti-pattern vì Middleware được thiết kế để xử lý các tác vụ xuyên suốt (Cross-cutting concerns) như Logging, Authentication, hoặc Caching. Nếu đưa logic nghiệp vụ vào đây, hệ thống sẽ gặp các vấn đề sau: 1. Khó kiểm thử (Unit Testing) do Middleware phụ thuộc vào Request/Response context. 2. Vi phạm nguyên tắc Single Responsibility Principle (SRP). 3. Khó tái sử dụng logic ở các tầng khác. Cách phân tách hợp lý: Middleware chỉ nên đóng vai trò là 'người gác cổng' hoặc 'bộ lọc'. Logic nghiệp vụ phải được đóng gói vào các Service Layer hoặc Domain Layer. Middleware chỉ nên gọi các Service này thông qua Dependency Injection và không được chứa các quy tắc nghiệp vụ phức tạp.

Rate Limiting Middleware giúp giới hạn số lượng Request từ một IP hoặc User trong một khoảng thời gian nhất định. Cơ chế thực hiện: 1. Sử dụng một kho lưu trữ tạm thời (như Redis hoặc In-memory cache) để đếm số lượng Request. 2. Mỗi khi có Request, Middleware kiểm tra key (thường là IP hoặc User ID) trong cache. 3. Nếu vượt quá ngưỡng (threshold), trả về mã lỗi HTTP 429 (Too Many Requests). Ví dụ cấu hình: Sử dụng thuật toán Token Bucket hoặc Fixed Window. Lưu ý: Cần đặt Middleware này ở vị trí đầu tiên trong Pipeline để chặn các request độc hại trước khi chúng đi sâu vào các tầng xử lý tốn kém tài nguyên phía sau.

Việc sử dụng DTO giúp tách biệt giữa cấu trúc dữ liệu của Database (Entity) và dữ liệu hiển thị cho Client (View/API response). Lợi ích: 1. Bảo mật: Tránh lộ các trường nhạy cảm như password_hash. 2. Tối ưu: Chỉ truyền tải những dữ liệu cần thiết. 3. Linh hoạt: Thay đổi cấu trúc Database không làm ảnh hưởng đến API contract. Vai trò của Middleware: Middleware có thể thực hiện việc Mapping tự động hoặc Validation dữ liệu đầu vào thông qua DTO. Ví dụ, sử dụng thư viện như AutoMapper hoặc FluentValidation trong một Middleware để đảm bảo dữ liệu trước khi đến Business Layer luôn đúng định dạng và an toàn.

Middleware hoạt động ở mức độ toàn cục (Global level) của ứng dụng web, xử lý mọi Request đi qua Pipeline trước khi đến Controller. Interceptor thường hoạt động ở mức độ Framework hoặc Service (như Axios Interceptor hoặc Spring Interceptor), tập trung vào việc can thiệp vào dữ liệu cụ thể của một Service hoặc một nhóm API. Khi nào nên dùng: 1. Dùng Middleware: Khi cần xử lý các tác vụ bao trùm toàn bộ ứng dụng như bảo mật, nén dữ liệu, đo lường thời gian phản hồi (Monitoring). 2. Dùng Interceptor: Khi cần xử lý logic cho một nhóm API cụ thể, ví dụ: tự động đính kèm Token vào Header của các Request gọi đến một Microservice nội bộ hoặc xử lý lỗi đặc thù cho một nhóm Controller.

Việc thiết lập các Security Headers là bắt buộc trong các ứng dụng Enterprise. Middleware đóng vai trò chèn các Header này vào mọi Response trả về từ Server. Các Header quan trọng bao gồm: 1. Content-Security-Policy (CSP): Ngăn chặn XSS bằng cách giới hạn nguồn script. 2. X-Content-Type-Options: Ngăn chặn trình duyệt tự động đoán định dạng file (MIME sniffing). 3. X-Frame-Options: Ngăn chặn Clickjacking bằng cách không cho phép trang web hiển thị trong thẻ iframe. Cách triển khai: Viết một Custom Middleware thực hiện context.Response.Headers.Append("X-Content-Type-Options", "nosniff") ngay trước khi gọi next() trong Pipeline. Điều này đảm bảo mọi phản hồi từ ứng dụng đều được bảo vệ đồng nhất.

1. Khái niệm Ubiquitous Language

Ubiquitous Language (Ngôn ngữ phổ quát) là một thuật ngữ cốt lõi trong Domain-Driven Design (DDD), đại diện cho một từ vựng chung được thống nhất và sử dụng xuyên suốt bởi tất cả các thành viên trong dự án, bao gồm cả Domain Experts (Chuyên gia nghiệp vụ), Software Engineers (Lập trình viên), Product Owners và Testers.