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

Bản chất vấn đề

Khi dữ liệu được lưu trong Cache (như Redis), hệ thống sẽ trả về dữ liệu từ Cache thay vì truy vấn trực tiếp từ Database. Nếu dữ liệu trong Database thay đổi nhưng Cache không được cập nhật kịp thời, người dùng sẽ thấy thông tin cũ (Stale Data).

Lý do chính

1. Bảo mật (Security): Tránh việc lộ các thông tin nhạy cảm như API Key, Database Password, Secret Key khi đẩy mã nguồn lên các hệ thống quản lý phiên bản như Git.
2. Tính linh hoạt (Flexibility): Cho phép thay đổi cấu hình giữa các môi trường (Development, Staging, Production) mà không cần phải build lại mã nguồn.
3. Tuân thủ 12-Factor App: Đây là một trong những nguyên tắc cốt lõi để xây dựng ứng dụng hiện đại, giúp tách biệt hoàn toàn cấu hình khỏi code.

Cách triển khai

Sử dụng các file .env cho môi trường cục bộ và các biến môi trường hệ thống (System Environment Variables) trên các nền tảng Cloud như AWS, Docker hoặc Kubernetes.

So sánh kiến trúc

• Monolithic: Toàn bộ chức năng của ứng dụng được đóng gói trong một đơn vị duy nhất. Dễ phát triển, dễ deploy ở giai đoạn đầu.
• Microservices: Ứng dụng được chia thành các dịch vụ nhỏ, độc lập, giao tiếp qua Network (HTTP/gRPC/Message Queue). Phức tạp trong vận hành nhưng linh hoạt trong mở rộng.

Khi nào chọn Monolithic?

1. Đội ngũ phát triển nhỏ: Việc quản lý hạ tầng cho Microservices đòi hỏi kiến thức chuyên sâu về DevOps.
2. Dự án mới (MVP): Cần tốc độ phát triển nhanh để đưa sản phẩm ra thị trường.
3. Độ phức tạp nghiệp vụ chưa cao: Việc chia nhỏ dịch vụ quá sớm sẽ gây lãng phí tài nguyên và làm chậm tiến độ phát triển.

Lời khuyên

Hãy bắt đầu với Modular Monolith (kiến trúc nguyên khối nhưng được phân chia module rõ ràng). Khi hệ thống đủ lớn và nhu cầu mở rộng các module độc lập trở nên cấp thiết, lúc đó mới thực hiện tách ra Microservices.

Định nghĩa

Idempotency (tính lũy đẳng) là thuộc tính của một thao tác mà khi thực hiện nhiều lần vẫn cho ra kết quả giống như thực hiện một lần duy nhất.

Bản chất của Race Condition

Race Condition (Điều kiện tranh chấp) xảy ra khi hai hoặc nhiều luồng cùng đọc và ghi dữ liệu chia sẻ mà không có cơ chế đồng bộ hóa, dẫn đến kết quả phụ thuộc vào thứ tự thực thi của các luồng (thứ tự này không thể đoán trước do hệ điều hành quản lý).

Định nghĩa Context Switching

Context Switching (Chuyển đổi ngữ cảnh) là quá trình hệ điều hành lưu lại trạng thái (Context, bao gồm giá trị thanh ghi, bộ đếm chương trình - Program Counter) của luồng đang chạy, và khôi phục trạng thái của luồng tiếp theo được lên lịch để chạy trên CPU.

Định nghĩa Callback Hell

Callback Hell (Địa ngục hàm gọi lại) là hiện tượng mã nguồn trở nên lồng nhau quá nhiều tầng các hàm callback (bất đồng bộ phụ thuộc lẫn nhau), tạo thành hình dạng giống kim tự tháp (Pyramid of Doom). Hiện tượng này thường xuất hiện khi xử lý các tác vụ tuần tự như: Kết nối DB -> Truy vấn dữ liệu -> Gọi API ngoài -> Xử lý file.

Bản chất vấn đề

Trong cấu trúc dữ liệu Linear Queue sử dụng mảng cố định, khi các thao tác Enqueue (thêm phần tử) và Dequeue (lấy phần tử) diễn ra liên tục, con trỏ quản lý đầu hàng đợi (Front) và cuối hàng đợi (Rear) sẽ tịnh tiến về phía cuối mảng.

Khác biệt cốt lõi

• Standard Queue (FIFO): Hoạt động theo nguyên tắc "Vào trước ra trước" (First In, First Out). Mọi phần tử đều có quyền bình đẳng, phần tử nào vào trước sẽ được xử lý trước.
• Priority Queue: Mỗi phần tử đi kèm với một độ ưu tiên (Priority). Phần tử có độ ưu tiên cao hơn sẽ được phục vụ trước, bất kể thứ tự thời gian chúng được đưa vào hàng đợi.

Cấu trúc dữ liệu ngầm bên dưới (Underlying Data Structure)

Priority Queue thường không được cài đặt bằng danh sách liên kết đơn thuần mà sử dụng cấu trúc Binary Heap (Max-Heap hoặc Min-Heap) để đảm bảo độ phức tạp thời gian cho các thao tác:

Nguyên nhân gây Queue Overflow

Khi tốc độ sản xuất message của Producer lớn hơn nhiều lần tốc độ tiêu thụ của Consumer trong một khoảng thời gian dài, hàng đợi sẽ dần đạt đến giới hạn dung lượng lưu trữ tối đa (Memory hoặc Disk).

Khái niệm cơ bản

• TTL (Time-to-Live): Thời gian sống tối đa của một message trong hàng đợi trước khi nó bị hủy hoặc chuyển hướng.
• Delayed Message (Hàng đợi trì hoãn): Cơ chế cho phép một message được đưa vào hàng đợi nhưng chỉ sẵn sàng để Consumer tiêu thụ sau một khoảng thời gian định trước.

Bài toán thực tế trong Enterprise

1. Quản lý đơn hàng thương mại điện tử:
   • Khi người dùng tạo đơn hàng nhưng chưa thanh toán, hệ thống đẩy một message vào Delayed Queue với thời gian trì hoãn là 15 phút.
   • Sau 15 phút, nếu đơn hàng chưa chuyển sang trạng thái 'Đã thanh toán', hệ thống sẽ tự động hủy đơn và hoàn lại kho.
2. Thử lại kết nối thất bại (Retry Mechanism):
   • Khi gọi API bên thứ ba bị lỗi, thay vì gọi lại liên tục ngay lập tức (gây nghẽn mạng), hệ thống đẩy message vào hàng đợi trì hoãn tăng dần (Exponential Backoff) để thử lại sau 1 phút, 5 phút, 15 phút.

Cách cài đặt phổ biến

• Trong RabbitMQ: Sử dụng Dead Letter Exchange (DLX kết hợp x-message-ttl).
• Trong Redis: Sử dụng Sorted Set với điểm số (score) là dấu thời gian thực thi (Timestamp).

Lời khuyên chuyên gia

Việc tận dụng TTL và Delayed Message giúp giảm tải đáng kể cho Database, loại bỏ hoàn toàn các tác vụ quét định kỳ (Cron Job / Polling) nặng nề đối với bảng dữ liệu lớn.

Trong kiến trúc SOA, một hệ thống lớn được chia thành hàng chục hoặc hàng trăm micro-services/Web services độc lập. Nếu mỗi dịch vụ đều phải tự kết nối về cơ sở dữ liệu trung tâm hoặc gọi một dịch vụ xác thực (Auth Service) riêng lẻ để kiểm tra quyền của người dùng cho mỗi request, hệ thống sẽ gặp vấn đề nghẽn cổ chai và độ trễ cao.

Trong môi trường phân tán của SOA, sự cố mạng hoặc sự chậm trễ từ một dịch vụ ngoại vi là điều không thể tránh khỏi. Nếu lập trình viên không áp dụng các biện pháp phòng vệ kỹ thuật, hệ thống sẽ dễ dàng rơi vào trạng thái tê liệt toàn diện.

Trong kiến trúc Service-Oriented Architecture (SOA), việc giám sát trạng thái của từng dịch vụ là cực kỳ quan trọng để đảm bảo tính sẵn sàng cao. Khi triển khai các Health Check, hệ thống thường sử dụng hai cơ chế chính:

Trong kiến trúc SOA, các dịch vụ thường xuyên gọi qua lại lẫn nhau. Nếu lập trình viên không chú ý đến tầng giao vận mạng, hiệu năng hệ thống sẽ sụt giảm mạnh do các nguyên nhân sau: