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

Bản chất của Indexing Policies

Mặc định, Azure Cosmos DB tự động index mọi thuộc tính của tất cả các tài liệu (Consistent Indexing). Điều này giúp mọi câu truy vấn đều hoạt động nhưng lại tiêu tốn lượng RU lớn khi thực hiện thao tác ghi (Write Operations) và chiếm dụng dung lượng lưu trữ.

Bản chất của Bulk Execution

Khi thực hiện hàng ngàn thao tác ghi độc lập (CreateItemAsync), ứng dụng phải chịu độ trễ mạng lớn và dễ gặp lỗi HTTP 429 do vượt quá giới hạn RU. Cơ chế Bulk Execution trong SDK cho phép gom nhóm (batching) các yêu cầu này lại và gửi đồng thời, tối ưu hóa việc tận dụng thông lượng được cấp phát.

Hạn chế của Partition Key truyền thống

Trong kiến trúc cũ, mỗi container chỉ được phép sử dụng một Partition Key duy nhất (ví dụ: /tenantId). Nếu một tenant nào đó có lượng dữ liệu và truy vấn lớn vượt trội so với các tenant khác, partition chứa tenant đó sẽ trở thành Hot Partition, gây lãng phí tổng tài nguyên và trả về lỗi 429 mặc dù các partition khác vẫn còn dư dung lượng.

Khi xử lý các bài toán Backtracking với trạng thái (State) có kích thước lớn trong các hệ thống Enterprise, việc sao chép trạng thái ở mỗi bước đệ quy sẽ dẫn đến chi phí bộ nhớ khổng lồ và áp lực lớn lên Garbage Collection. Để tối ưu hóa không gian bộ nhớ, chúng ta cần áp dụng kỹ thuật In-place State Mutation kết hợp với cơ chế Hoàn tác (Undo/Revert).

Trong các hệ thống Enterprise, các thuật toán Backtracking truyền thống chạy theo chiều sâu (DFS) có thể rơi vào trạng thái vòng lặp vô tận hoặc chiếm dụng CPU quá lâu nếu không gian tìm kiếm quá lớn. Việc kết hợp Iterative Deepening với Backtracking giúp kiểm soát thời gian thực thi hiệu quả.

Việc gỡ lỗi các thuật toán Backtracking trong môi trường Microservices rất phức tạp vì không gian trạng thái bị phân rã và việc đệ quy sâu tạo ra hàng nghìn bước tính toán. Để xử lý vấn đề này, chúng ta cần triển khai cơ chế Structured Logging kết hợp Sampling.

Backtracking thuần túy (Standard Backtracking) chỉ kiểm tra tính hợp lệ của trạng thái hiện tại sau khi đã gán giá trị. Điều này dẫn đến việc hệ thống có thể đi sâu vào các nhánh cụt mà mãi đến các bước sau mới phát hiện ra mâu thuẫn. Forward Checking ra đời để giải quyết triệt để điểm yếu này.

Khi thuật toán Backtracking thực hiện việc thay đổi trạng thái liên quan đến cơ sở dữ liệu hoặc các tài nguyên bên ngoài (External APIs) trong các hệ thống tài chính, việc xảy ra lỗi giữa chừng có thể làm sai lệch dữ liệu toàn cục nếu không có cơ chế quản lý giao dịch chuẩn xác.

Khi xảy ra hiện tượng cạn kiệt Connection Pool, cần thực hiện các bước: 1. Giám sát: Kiểm tra metrics của Connection Pool (Active connections, Idle connections, Wait time). 2. Phân tích nguyên nhân: Kiểm tra các truy vấn chậm (Slow Queries) gây chiếm dụng kết nối lâu, hoặc lỗi rò rỉ kết nối (Connection Leak) do không đóng kết nối sau khi sử dụng. 3. Tối ưu hóa: Tối ưu hóa các câu lệnh SQL bằng cách đánh Index, sử dụng Read Replica để giảm tải cho Master, hoặc áp dụng Caching (Redis) để giảm số lượng truy vấn xuống Database. 4. Cấu hình: Điều chỉnh tham số pool size phù hợp với khả năng chịu tải của Database server và sử dụng cơ chế Timeout hợp lý để giải phóng kết nối bị treo.

Database Sharding là kỹ thuật phân mảnh cơ sở dữ liệu thành các phần nhỏ hơn và lưu trữ trên các server khác nhau để tăng khả năng mở rộng ngang (Horizontal Scaling). Vấn đề lớn nhất là Rebalancing dữ liệu khi thêm Shard mới. Để giải quyết, chúng ta nên sử dụng Consistent Hashing thay vì thuật toán Modulo truyền thống. Với Consistent Hashing, khi thêm một node mới, chỉ một phần nhỏ dữ liệu cần phải di chuyển thay vì toàn bộ dữ liệu. Ngoài ra, có thể sử dụng Virtual Nodes để phân bổ dữ liệu đồng đều hơn trên các vật lý server, tránh hiện tượng Hotspot.

Để thiết kế hệ thống Notification hiệu quả, cần áp dụng kiến trúc bất đồng bộ (Asynchronous Architecture): 1. Sử dụng Message Queue (như Kafka hoặc RabbitMQ) để tách biệt giữa dịch vụ phát sinh sự kiện và dịch vụ gửi thông báo. 2. Notification Worker: Xây dựng các worker chuyên biệt để tiêu thụ message từ queue và thực hiện gửi thông báo qua các Provider (Email, SMS, Push). 3. Throttling: Áp dụng cơ chế giới hạn tốc độ gửi để tránh bị các nhà cung cấp dịch vụ chặn do spam. 4. Retry Mechanism: Thiết kế cơ chế thử lại với chiến lược Exponential Backoff cho các thông báo gửi thất bại. Cách tiếp cận này đảm bảo hệ thống chính không bị block khi quá trình gửi thông báo gặp sự cố.

Để đảm bảo an toàn trong giao tiếp giữa các Microservices, nên áp dụng mô hình Zero Trust: 1. Sử dụng JWT (JSON Web Token) để truyền tải thông tin định danh người dùng và quyền hạn giữa các dịch vụ. 2. API Gateway: Đóng vai trò là điểm truy cập duy nhất, thực hiện xác thực token trước khi chuyển tiếp request vào hệ thống nội bộ. 3. Mutual TLS (mTLS): Thiết lập kết nối được mã hóa hai chiều giữa các dịch vụ để đảm bảo chỉ các dịch vụ được tin tưởng mới có thể giao tiếp với nhau. 4. Service Mesh: Sử dụng công cụ như Istio để quản lý chính sách bảo mật, kiểm soát truy cập (RBAC) và giám sát lưu lượng mạng một cách tập trung mà không cần thay đổi code của từng service.

Trong các hệ thống phân tán, Modulo Hashing sử dụng công thức hash(key) % N (với N là số lượng node máy chủ). Khi một node chết đi hoặc thêm node mới (N thay đổi), hầu như toàn bộ các khóa (keys) phải được tính toán lại và di chuyển sang node khác, gây ra hiện tượng cache stampede và quá tải hệ thống.

Trong Hash Table sử dụng phương pháp Open Addressing (địa chỉ mở), khi xảy ra va chạm, thuật toán sẽ tìm kiếm vị trí trống tiếp theo theo một chuỗi thăm dò (probing sequence).

HashMap truyền thống (ví dụ trong Java hoặc C++ STL) thường tiêu tốn nhiều bộ nhớ phụ trợ (overhead) do các con trỏ liên kết trong Separate Chaining hoặc các đối tượng bọc node. Đối với các hệ thống Enterprise xử lý hàng trăm triệu bản ghi, overhead này dẫn đến lãng phí RAM nghiêm trọng và gây áp lực lớn lên Garbage Collection (GC).