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

Bản chất vấn đề

Khi làm việc với các bài toán yêu cầu cập nhật giá trị trên một đoạn lớn (ví dụ: cộng thêm $x$ vào tất cả các phần tử từ vị trí $L$ đến $R$) và truy vấn trên khoảng (ví dụ: tìm tổng hoặc giá trị lớn nhất từ $L$ đến $R$), việc cập nhật từng phần tử sẽ làm độ phức tạp thời gian tăng lên $O(N)$ cho mỗi lần cập nhật, dẫn đến Time Limit Exceeded trong các hệ thống quy mô lớn.

Bản chất vấn đề

Trong các nền tảng thương mại điện tử lớn, tính năng Autocomplete (Gợi ý tìm kiếm) yêu cầu tốc độ phản hồi dưới 50ms. Nếu sử dụng câu lệnh LIKE '%keyword%' trên cơ sở dữ liệu quan hệ, hệ thống sẽ phải thực hiện Table Scan, làm giảm hiệu năng nghiêm trọng. Cấu trúc dữ liệu Trie giúp giải quyết bài toán tìm kiếm tiền tố (Prefix Search) với độ phức tạp $O(M)$ (với $M$ là độ dài từ khóa). Tuy nhiên, khi người dùng gõ sai chính tả hoặc sử dụng ký tự đại diện (Wildcard), Trie truyền thống cần được mở rộng.

Bản chất vấn đề

B+Tree là tiêu chuẩn vàng cho các hệ thống CSDL quan hệ truyền thống nhờ khả năng tối ưu hóa truy vấn đọc (Read-Heavy) thông qua việc duy trì tính cân bằng và giảm số lần truy cập ổ đĩa (Disk I/O). Tuy nhiên, khi hệ thống chuyển sang mô hình Write-Heavy (như ghi nhật ký sự kiện, IoT telemetry, high-frequency trading), B+Tree gặp hiện tượng phân mảnh ổ đĩa và chi phí ghi ngẫu nhiên (Random Write IOPS) quá lớn, dẫn đến suy giảm hiệu năng nghiêm trọng.

Bản chất cơ chế Token Authentication tại tầng CDN

Trong các hệ thống phân phối nội dung số lớn (như VOD hoặc Live Streaming), việc bảo vệ bản quyền tài nguyên là tối quan trọng. Thay vì chuyển yêu cầu xác thực về Origin Server cho mỗi tệp tin .ts hay .m4u, chúng ta cấu hình tầng Edge Server của CDN tự động kiểm tra tính hợp lệ của token.

Khái niệm cơ bản

Để tối ưu hóa hiệu năng mạng cho ứng dụng Enterprise, việc lựa chọn trung tâm dữ liệu phản hồi là yếu tố then chốt. Anycast Routing là công nghệ mạng cho phép nhiều máy chủ ở các vị trí địa lý khác nhau cùng quảng bá (advertise) chính xác cùng một địa chỉ IP công cộng (IP Address) thông qua giao thức định tuyến Border Gateway Protocol (BGP).

Bản chất hiện tượng Cache Stampede

Cache Stampede xảy ra khi một tài nguyên cực kỳ hot (ví dụ: trang chủ của một sự kiện Flash Sale) bị hết hạn cache (Expired) trên toàn bộ hệ thống CDN Edge nodes cùng một thời điểm. Hàng triệu request đồng thời đổ về Edge node, và vì tài nguyên không còn trong cache, tất cả các Edge nodes này đồng loạt chuyển tiếp (forward) request đó về Origin Server gây ra hiện tượng nghẽn cổ chai đột ngột.

Bản chất vấn đề

Trong hệ sinh thái Ethereum, ECDSA trên đường cong secp256k1 được sử dụng để ký và xác thực các giao dịch cũng như thông điệp. Việc cho phép người dùng ký thông điệp bằng ví cá nhân ở phía Off-chain giúp tiết kiệm tối đa chi phí Gas vì không phải thực hiện giao dịch On-chain cho mỗi hành động xác thực.

Bản chất vấn đề

Blockchain cơ sở (Layer 1 như Ethereum) gặp nút thắt cổ chai về hiệu năng (TPS thấp, phí Gas cao) do mọi node trong mạng lưới phải thực thi và lưu trữ toàn bộ lịch sử giao dịch. Layer 2 Rollups ra đời nhằm thực thi các giao dịch ngoài chuỗi chính nhưng vẫn kế thừa tính bảo mật từ Layer 1.

Bản chất vấn đề

Trong Máy ảo Ethereum (EVM), mỗi khe lưu trữ (Storage Slot) có kích thước cố định là 32 bytes (256 bits). Việc đọc và ghi dữ liệu trên Storage là các thao tác tốn kém chi phí Gas nhất trong EVM.

Bản chất vấn đề

Trong kiến trúc Microservices kết hợp Domain-Driven Design, mỗi Bounded Context sở hữu một Database riêng biệt. Việc sử dụng Distributed Transactions (như Two-Phase Commit - 2PC) gây ra hiện tượng giảm hiệu năng nghiêm trọng, khóa tài nguyên và vi phạm tính cô lập của Microservices. Giải pháp tiêu chuẩn Enterprise là sử dụng mô hình Eventual Consistency thông qua Saga Pattern.

Bản chất vấn đề

Trong Domain-Driven Design, một Aggregate Root chịu trách nhiệm duy trì tính toàn vẹn dữ liệu (Invariants) của toàn bộ Aggregate. Nếu một Aggregate chứa một lượng lớn các thực thể con (ví dụ: một Order chứa hàng triệu OrderItem hoặc một BankAccount chứa hàng triệu Transaction), việc tải toàn bộ Aggregate này qua Repository sẽ gây ra các vấn đề nghiêm trọng:

Bản chất vấn đề

Khi một nghiệp vụ quan trọng xảy ra trong một Aggregate (ví dụ: Đã tạo đơn hàng thành công), hệ thống thường cần thực hiện các tác vụ phụ khác như gửi email xác nhận, cập nhật kho hàng, hoặc tính điểm thưởng. Lập trình viên ít kinh nghiệm thường gọi trực tiếp các Service liên quan ngay bên trong phương thức của Aggregate hoặc Application Service.

Bản chất của Global Server Load Balancing (GSLB) qua DNS

Global Server Load Balancing (GSLB) là kỹ thuật phân phối lưu lượng truy cập mạng đến các trung tâm dữ liệu (Datacenters) khác nhau trên toàn cầu. Khác với Load Balancer truyền thống hoạt động ở tầng mạng hoặc tầng ứng dụng trong một trung tâm dữ liệu cục bộ, GSLB thường hoạt động dựa trên cơ chế phân giải tên miền (DNS).

Khái niệm cơ bản

• Server-Side Load Balancing: Mô hình truyền thống nơi client gửi yêu cầu đến một Load Balancer tập trung (như NGINX, AWS ALB), sau đó Load Balancer này mới phân phối đến các Backend Server.
• Client-Side Load Balancing: Mô hình mà phía client (trong kiến trúc Microservices, đây chính là các Service gọi API lẫn nhau) tự duy trì danh sách các instance của Service đích và tự quyết định chọn instance nào để gửi request.

Sự cần thiết của Client-Side Load Balancing trong Microservices

Trong một hệ thống Microservices phức tạp, việc để mọi giao tiếp nội bộ (East-West Traffic) đi qua một Server-Side Load Balancer trung tâm sẽ tạo ra những điểm nghẽn nghiêm trọng:

Bản chất của Thundering Herd Problem trong Load Balancing

Hiện tượng Thundering Herd xảy ra khi một lượng lớn các tiến trình hoặc request đồng thời chờ đợi một sự kiện, và khi sự kiện đó xảy ra, tất cả cùng đồng loạt truy cập vào hệ thống gây ra quá tải tức thời (Spike). Trong bối cảnh Load Balancing, hiện tượng này thường xuất hiện khi: