Khi nào nên sử dụng Thread-per-request Model so với Event-Driven Non-blocking Model trong thiết kế API Backend hiện đại?

Question

Accepted Answer

Khái niệm cốt lõi

Thread-per-request Model: Mỗi HTTP request được xử lý trọn vẹn bởi một Thread riêng biệt trong suốt vòng đời của nó (Ví dụ: Spring Boot truyền thống với Tomcat).
Event-Driven Non-blocking Model: Sử dụng một số ít các Thread (thường bằng số lượng CPU core) để xử lý các sự kiện thông qua Event Loop và Callback/Reactive (Ví dụ: Node.js, Netty, Spring WebFlux).

Tiêu chí lựa chọn kỹ thuật

I/O Bound vs CPU Bound:
Nếu ứng dụng chủ yếu chờ đợi I/O (truy vấn Database chậm, gọi API bên thứ ba): Event-Driven Non-blocking tối ưu hơn rất nhiều vì không lãng phí tài nguyên để cấp phát Stack cho hàng ngàn Thread đang đứng chờ.
Nếu ứng dụng thực hiện các thuật toán tính toán nặng, mã hóa, xử lý ảnh (CPU Bound): Thread-per-request hoặc kết hợp Thread Pool riêng là lựa chọn an toàn hơn để tránh làm nghẽn Event Loop.

Độ phức tạp khi Debug:
Mô hình Thread-per-request dễ debug hơn nhờ Stack Trace rõ ràng.
Mô hình Non-blocking có Stack Trace phức tạp hơn do tính chất bất đồng bộ qua nhiều callback hoặc reactive operator.

Lưu ý kinh nghiệm thực chiến
Với Java 21+, công nghệ Virtual Threads (Project Loom) đã thu hẹp khoảng cách này bằng cách cho phép viết code theo phong cách Thread-per-request đơn giản nhưng chạy trên nền tảng Non-blocking I/O ở tầng kernel, giúp đạt hiệu năng cao tương đương Event-Driven.