Một nhà phát triển đã cắt giảm chi phí tính toán của cơ sở dữ liệu serverless Neon bằng cách kéo dài khoảng thời gian polling ở phía client từ 30 giây lên 15 phút. Khoảng nghỉ dài hơn cho phép cơ sở dữ liệu ở trạng thái rảnh rỗi đủ lâu để scale to zero, loại bỏ các credit tính toán mà một chu kỳ polling 30 giây liên tục sẽ tiêu tốn.

Neon tính phí cho mỗi giây mà compute engine của họ hoạt động. Trong một thiết lập serverless điển hình, bất kỳ yêu cầu nào—dù nhỏ đến đâu—cũng sẽ giữ cho engine luôn ở trạng thái hoạt động. Dashboard trên TV của tác giả đã truy vấn cơ sở dữ liệu mỗi nửa phút một lần, mặc dù dữ liệu hiển thị chỉ thay đổi khi người dùng thực hiện đồng bộ hóa thủ công hoặc khi một buổi phát sóng mới bắt đầu. Mô hình đó đã ngăn cản compute pool của Neon đạt đến trạng thái zero (trạng thái ngừng tính phí), làm tăng vọt chi phí hiển thị trên dashboard của Vercel một cách thường xuyên.

Tại sao việc polling ban đầu lại quan trọng

  • Dashboard là một component React thuần túy ở phía client, vì vậy mỗi phiên trình duyệt sẽ truy cập trực tiếp vào Neon.
  • Cách tính giá của Neon gắn liền chi phí với thời gian tính toán thực tế, chứ không phải số lượng yêu cầu, vì vậy một lần truy cập mỗi 30 giây sẽ duy trì một mức phí cơ bản.
  • Việc giám sát trên Vercel của tác giả cho thấy sự tương quan giữa lưu lượng truy cập và mức sử dụng compute của Neon, xác nhận rằng việc polling đã giữ cho cơ sở dữ liệu luôn hoạt động.

Các giải pháp thay thế không thành công

Một kỹ thuật debounce nhanh—trì hoãn yêu cầu sau tương tác cuối cùng của người dùng—đã không giúp ích gì vì bộ đếm thời gian vẫn kích hoạt mỗi 30 giây. Tôi cũng đã thử sử dụng Vercel Edge Functions, nhưng việc đó làm tăng thêm quá nhiều sự phức tạp.

Cách khắc phục đơn giản

Thay đổi mã nguồn duy nhất cần thiết là thay thế một hằng số định nghĩa khoảng thời gian làm mới:

  • Từ 30 giây → 5 phút
  • Sau đó 5 phút → 15 phút

Ở mức 15 phút, Neon có đủ thời gian để nhận biết trạng thái không hoạt động và spin down các tài nguyên tính toán. Dashboard vẫn hoạt động bình thường: người dùng vẫn thấy dữ liệu mới nhất khi họ làm mới thủ công, và các lần polling tự động thỉnh thoảng sẽ bắt được buổi phát sóng mới mà không gây ra sự trao đổi dữ liệu liên tục.

Tại sao vẫn nên giữ polling ở phía client?

  1. Sự đơn giản – Không cần thêm các serverless function hay các bước build bổ sung.
  2. Kỳ vọng của người dùng – Dashboard đã hoạt động giống như một ứng dụng client; một cú nhấp chuột thủ công vẫn mang lại kết quả cập nhật tức thì.
  3. Sự tương thích với mô hình chi phí – Neon tính phí theo từng giây tính toán, không phải theo từng yêu cầu, vì vậy việc giảm tần suất sẽ trực tiếp cắt giảm hóa đơn.

Bài học cho các nhà phát triển serverless

  • Hãy điều chỉnh tần suất polling phù hợp với nhịp độ cập nhật thực tế của dữ liệu. Nếu một tập dữ liệu chỉ thay đổi vài lần mỗi giờ, khoảng thời gian 15 phút thường là đủ.
  • Polling thường xuyên trong môi trường serverless là một tác nhân gây tốn kém chi phí tiềm ẩn; chỉ cần một yêu cầu dư thừa mỗi phút cũng có thể khiến cơ sở dữ liệu không bao giờ có thể scale down.
  • Những tinh chỉnh cấu hình nhỏ có thể mang lại hiệu quả tiết kiệm lớn mà không cần phải đại tu kiến trúc.

Điểm mấu chốt là: chỉ một thay đổi hằng số duy nhất đã biến một cơ sở dữ liệu luôn ở trạng thái hoạt động thành một thành phần serverless thực thụ, giúp cắt giảm chi phí tính toán trong khi vẫn duy trì được tính hữu dụng của dashboard. Đối với bất kỳ đội ngũ nào đang sử dụng Neon hoặc các dịch vụ tính toán theo giây tương tự, việc xem xét lại các khoảng thời gian polling là một giải pháp nhanh chóng và xứng đáng để thử nghiệm ngay hôm nay.