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

Bản chất của Deferred Execution

Deferred Execution có nghĩa là truy vấn LINQ không được thực thi ngay tại thời điểm định nghĩa, mà chỉ thực thi khi dữ liệu được truy xuất (ví dụ: thông qua vòng lặp foreach, hoặc các phương thức như ToList(), ToArray(), Count()).

Vấn đề

Việc viết các câu lệnh if-else lồng nhau để xây dựng truy vấn LINQ là một anti-pattern khiến code khó bảo trì.

Nguyên nhân

Khi thực hiện GroupBy, Entity Framework thường phải tải dữ liệu về bộ nhớ hoặc tạo ra các câu lệnh SQL phức tạp với các hàm tổng hợp (Aggregate functions) không được tối ưu, dẫn đến việc quét bảng (Table Scan) thay vì sử dụng Index.

Bản chất vấn đề

LINQ to Entities được thiết kế để làm việc với một DbContext duy nhất gắn liền với một Schema Database cụ thể. Việc cố gắng join dữ liệu giữa các Context khác nhau sẽ buộc LINQ phải thực hiện truy vấn trên Client-side (về bộ nhớ), dẫn đến việc tải toàn bộ dữ liệu của cả hai bảng về ứng dụng.

Vấn đề

Việc sử dụng vòng lặp để cập nhật từng bản ghi (Update từng dòng) sẽ tạo ra hàng loạt câu lệnh SQL UPDATE riêng lẻ, gây áp lực cực lớn lên Database Transaction Log.

Việc sử dụng next/dynamic cho phép chúng ta trì hoãn việc tải các component hoặc thư viện nặng cho đến khi cần thiết (lazy loading). Điều này giúp giảm đáng kể kích thước bundle ban đầu (Initial Bundle Size), từ đó cải thiện chỉ số Largest Contentful Paint (LCP) và thời gian tương tác (Time to Interactive).

React Server Components (RSC) là một mô hình kiến trúc mới nơi các component được render hoàn toàn trên server trước khi gửi kết quả (dạng serialized format) xuống client.

Việc bảo mật route trong Next.js thường được thực hiện thông qua Middleware, nơi chúng ta có thể kiểm tra token trước khi request được chuyển đến Server Components hoặc Route Handlers.

Khi làm việc với các thư viện như Prisma, Mongoose hoặc các SDK bên thứ ba, chúng ta không thể dùng cơ chế cache của fetch API. Thay vào đó, ta sử dụng hàm unstable_cache từ next/cache.

Đây là hai chỉ thị (directives) cốt lõi để phân định ranh giới giữa Client và Server trong kiến trúc App Router.

Trong môi trường Microservices, việc duy trì tính nhất quán dữ liệu thường được giải quyết thông qua mô hình Saga Pattern. Thay vì sử dụng giao dịch ACID tập trung, chúng ta chia nhỏ giao dịch thành chuỗi các bước cục bộ. Mỗi bước sẽ cập nhật dữ liệu của một service và phát ra một sự kiện (Event) để kích hoạt bước tiếp theo. Nếu một bước thất bại, hệ thống sẽ thực hiện các giao dịch bù trừ (Compensating Transactions) để hoàn tác các thay đổi trước đó. Có hai cách tiếp cận chính: Choreography (các dịch vụ tự giao tiếp qua Message Broker như RabbitMQ hoặc Kafka) và Orchestration (một service điều phối trung tâm quản lý luồng xử lý). Việc sử dụng Saga giúp hệ thống đạt được tính nhất quán cuối cùng (Eventual Consistency) mà không làm giảm hiệu năng hệ thống.

Mặc dù cả Worker Threads và Child Processes đều giúp giải quyết vấn đề chặn Event Loop, Worker Threads mang lại ưu thế vượt trội về hiệu năng và tài nguyên. Child Processes tạo ra các tiến trình độc lập với bộ nhớ riêng, dẫn đến chi phí khởi tạo cao và tốn kém RAM. Ngược lại, Worker Threads chia sẻ cùng một không gian bộ nhớ trong cùng một tiến trình Node.js, giúp việc truyền dữ liệu giữa các thread nhanh hơn thông qua SharedArrayBuffer. Điều này giúp giảm đáng kể overhead khi quản lý tài nguyên hệ thống, đặc biệt trong các ứng dụng Enterprise cần xử lý song song các tác vụ như mã hóa, nén dữ liệu hoặc xử lý ảnh mà không làm ảnh hưởng đến luồng xử lý I/O chính.

Caching tại tầng Application giúp giảm tải cho Database và tăng tốc độ phản hồi. In-memory cache cục bộ (như biến global hoặc thư viện node-cache) chỉ tồn tại trong phạm vi của một tiến trình, dẫn đến vấn đề dữ liệu không đồng nhất khi ứng dụng chạy trên nhiều instance (Scale-out). Redis đóng vai trò là một Distributed Cache, cho phép tất cả các instance của ứng dụng truy cập vào cùng một nguồn dữ liệu duy nhất. Điều này đảm bảo tính nhất quán, hỗ trợ các cấu trúc dữ liệu phức tạp, khả năng lưu trữ bền vững (Persistence) và cơ chế TTL (Time-to-live) giúp tự động giải phóng bộ nhớ, từ đó tối ưu hóa hiệu năng cho các hệ thống có lưu lượng truy cập lớn.

ReDoS xảy ra khi một biểu thức chính quy (Regex) được thiết kế kém, dẫn đến thời gian xử lý tăng theo cấp số nhân (Catastrophic Backtracking) khi gặp các chuỗi đầu vào đặc biệt. Để ngăn chặn: 1. Tránh sử dụng các Regex phức tạp với các nhóm lồng nhau hoặc lặp lại không kiểm soát. 2. Sử dụng các thư viện kiểm tra Regex an toàn như safe-regex để phát hiện các mẫu có nguy cơ gây lỗi. 3. Luôn giới hạn độ dài của chuỗi đầu vào trước khi thực hiện kiểm tra. 4. Sử dụng các giải pháp thay thế như String.indexOf() hoặc các thư viện parser chuyên dụng nếu logic xử lý quá phức tạp. Việc kiểm soát chặt chẽ đầu vào ngay tại tầng Middleware là bước quan trọng nhất để bảo vệ ứng dụng.

Rate Limiting là kỹ thuật giới hạn số lượng yêu cầu từ một client trong một khoảng thời gian nhất định. Trong môi trường Enterprise, việc triển khai tại tầng code Node.js thường sử dụng các middleware như express-rate-limit kết hợp với Redis để lưu trữ trạng thái đếm số lượng request. Cách tiếp cận này cho phép đồng bộ hóa giới hạn trên nhiều instance của ứng dụng. Cấu trúc logic bao gồm: xác định định danh người dùng (thường là IP hoặc User ID), kiểm tra số lượng request hiện tại trong Redis, và trả về mã lỗi 429 (Too Many Requests) nếu vượt quá ngưỡng. Đối với các hệ thống lớn, giải pháp tối ưu hơn là đẩy việc Rate Limiting ra tầng Gateway hoặc Load Balancer như Nginx hoặc Kong để giảm tải cho ứng dụng Node.js.