Short Polling: "Đứa con hư" Hay Giải Pháp Quốc Dân Trong System Design?

Chào anh em lại là mình đây

Trong thế giới Real-time Communication, chúng ta thường nghe về những "kỹ thuật cao siêu" như WebSockets, gRPC hay Server-Sent Events (SSE). Tuy nhiên, có một kỹ thuật "cổ xưa" nhưng vẫn xuất hiện trong mọi ngõ ngách của hệ thống lớn, từ việc check trạng thái thanh toán đến đợi background job: Short Polling.

Hôm nay, hãy cùng mình mổ xẻ xem Short Polling thực chất là gì, tại sao nó bị "ghét" và khi nào thì nó lại là "cứu cánh" cho anh em Dev nhé.

1. Short Polling là gì? (The "Are we there yet?" Problem)

Hãy tưởng tượng bạn đang lái xe và đứa con ở ghế sau cứ 5 giây lại hỏi một lần: "Bố ơi, đến nơi chưa?".

Nếu chưa đến, bạn trả lời: "Chưa".
5 giây sau nó lại hỏi tiếp.

Đó chính là Short Polling.

Về mặt kỹ thuật, Client sẽ liên tục gửi các HTTP Request lên Server theo một khoảng thời gian cố định (Interval) để kiểm tra xem có dữ liệu mới hay không. Server nhận yêu cầu, kiểm tra Database/Cache và trả về kết quả ngay lập tức (dù có dữ liệu hay không) rồi đóng kết nối.

2. Ưu và nhược điểm: Đừng để vẻ ngoài đánh lừa

Ưu điểm (The Good)

Dễ triển khai (Simplicity): Chỉ cần một hàm setInterval ở Frontend và một API GET ở Backend. Không cần setup phức tạp như WebSocket Server hay xử lý Connection State.
Stateless: Server không cần giữ kết nối mở (persistent connection). Điều này giúp việc Scaling (Auto-scaling) trở nên cực kỳ đơn giản.
Khả năng tương thích: Chạy tốt trên mọi trình duyệt và mọi loại Proxy/Load Balancer mà không cần cấu hình đặc biệt.

Nhược điểm (The Bad)

Lãng phí tài nguyên (Overhead): Mỗi request đều phải đi kèm đầy đủ HTTP Header (thường nặng hơn dữ liệu thực tế).
Gây áp lực cho Database: Nếu 10.000 User cùng poll mỗi giây, Database của bạn sẽ "ăn" 10.000 Query chỉ để trả về kết quả "Không có gì mới".
Độ trễ (Latency): Nếu dữ liệu xuất hiện ngay sau khi một request vừa kết thúc, User phải đợi hết khoảng nghỉ (interval) mới nhận được dữ liệu ở request tiếp theo.

3. Case Study: Khi nào nên dùng Short Polling?

Đừng vì "WebSockets xịn hơn" mà bỏ qua Short Polling. Trong một số trường hợp tại các hệ thống lớn (như Hasaki hay các sàn TMĐT), Short Polling vẫn là lựa chọn số 1:

Trạng thái thanh toán (Payment Status): Khi User quét mã QR, Frontend sẽ poll API mỗi 2-3 giây để check xem tiền đã vào chưa. Vì việc này chỉ diễn ra trong thời gian ngắn (30s - 1p), Short Polling là đủ và an toàn.
Theo dõi Background Job: Khi bạn xuất một file Excel nặng hàng triệu dòng, Server trả về một job_id. Frontend sẽ poll để hiển thị thanh Progress Bar.
Hệ thống có ít thay đổi: Nếu dữ liệu chỉ thay đổi vài phút một lần, việc duy trì một kết nối WebSocket là cực kỳ lãng phí.

4. Triển khai "Sạch" (Clean Implementation)

Thay vì chỉ setInterval mù quáng, anh em nên áp dụng kỹ thuật Recursive Timeout để tránh tình trạng request sau "đè" request trước nếu mạng chậm.

Code ví dụ (Node.js/JavaScript):

async function pollStatus(jobId) {
    try {
        const response = await fetch(`/api/status/${jobId}`);
        const data = await response.json();

        if (data.status === 'COMPLETED') {
            console.log("Xong rồi nhé anh em!");
            return data.result;
        }

        // Nếu chưa xong, đợi 3s rồi mới gọi lại (Recursive)
        setTimeout(() => pollStatus(jobId), 3000);
    } catch (error) {
        // Handle lỗi mạng, retry logic ở đây
        setTimeout(() => pollStatus(jobId), 5000);
    }
}

5. Bí kíp tối ưu cho anh em Backend

Nếu buộc phải dùng Short Polling cho hệ thống nhiều User, hãy nhớ:

Caching thần chưởng: Kết quả của poll request PHẢI được lưu ở Redis hoặc Memcached. Đừng bao giờ chọc thẳng vào DB ở mỗi request polling.
Exponential Backoff: Tăng dần thời gian chờ giữa các lần poll nếu chưa thấy dữ liệu (lần đầu 2s, lần sau 4s, 8s...). Điều này giúp giảm tải cho Server khi User treo máy lâu.
HTTP 304 Not Modified: Nếu dữ liệu không đổi, hãy trả về status code 304 để giảm dung lượng bandwidth.

Kết luận

Short Polling không xấu, nó chỉ xấu khi bạn dùng sai chỗ. Nếu bạn cần sự đơn giản, tin cậy và không muốn đau đầu với việc quản lý hàng triệu kết nối WebSocket cùng lúc, hãy mạnh dạn dùng Short Polling nhưng kèm theo một chiến lược Caching hợp lý.

Anh em thường dùng kỹ thuật nào cho tính năng Real-time của mình? Chia sẻ bên dưới để mình cùng thảo luận nhé!