Khi bắt đầu xây dựng một sản phẩm web bằng AI coding agent, lựa chọn phổ biến và hấp dẫn nhất của hầu hết mọi người là tận dụng tối đa các gói dịch vụ miễn phí: đưa ứng dụng lên Vercel, lưu trữ dữ liệu với Supabase, gửi email qua Resend, chặn spam bằng Upstash Redis, và nhận thanh toán tự động qua PayOS.
Trên bảng tính lý thuyết, hóa đơn hạ tầng của bạn trong những tháng đầu tiên tròn trĩnh 0 đồng.
Nhưng chi phí thực sự của việc xây dựng sản phẩm không chỉ đo bằng số tiền bạn trả cho nhà cung cấp vào cuối tháng. Chi phí thực sự nằm ở những chiếc trần kỹ thuật ngầm mà gói miễn phí dựng lên — và cách chúng âm thầm buộc bạn phải thay đổi cấu trúc mã nguồn khi dự án bắt đầu đón những người dùng thật đầu tiên.
Sau nhiều tuần vận hành một hệ thống thật với hàng chục bài viết và sản phẩm số, tôi nhận ra các giới hạn hạ tầng không bao giờ xuất hiện dưới dạng một thông báo tăng giá đơn giản. Chúng xuất hiện dưới bốn hình thái rất khác nhau, và mỗi hình thái đòi hỏi một cách ứng xử kỹ thuật riêng biệt.
1. Trần đếm được: Khi số lượng ép bạn phải gom việc
Loại trần đầu tiên là thứ dễ nhận biết nhất: các con số giới hạn hiển thị công khai ngay trên bảng tính năng của nhà cung cấp.
Ví dụ điển hình nhất là giới hạn tác vụ tự động (Cron Job) trên Vercel. Ở gói cá nhân miễn phí (Hobby), nền tảng này cho phép tối đa 2 lịch chạy định kỳ trong cấu hình dự án, và tần suất kích hoạt chỉ được phép tối đa một lần mỗi ngày.
Khi sản phẩm bắt đầu mở rộng tính năng, bạn sẽ nhanh chóng thấy danh sách việc cần chạy tự động tăng lên:
- Mỗi ngày cần quét kiểm tra trạng thái sức khỏe của toàn bộ hệ thống.
- Cần đối soát các đơn hàng chưa hoàn tất để tránh trường hợp người mua trả tiền nhưng chưa nhận được quyền truy cập.
- Cần gửi email chăm sóc học viên và phát hành bản tin định kỳ.
- Cần dọn dẹp các phiên làm việc tạm thời và cập nhật lại bảng thống kê năng lực.
Nếu tư duy theo cách thông thường, mỗi tác vụ đó sẽ là một cron job riêng biệt với lịch chạy độc lập. Nhưng khi bị chặn ở trần 2 lịch định kỳ, bạn không thể cứ viết thêm việc là lại tạo thêm một lịch mới.
Giải pháp bắt buộc lúc này là gom toàn bộ các tác vụ định kỳ vào đúng một luồng điều phối duy nhất chạy vào đầu giờ sáng.
Trong luồng điều phối đó, từng công việc phải được bọc trong một khối bảo vệ riêng biệt. Nếu tác vụ gửi email bị lỗi kết nối, nó phải tự ghi nhận và bỏ qua để tác vụ đối soát thanh toán tiếp tục chạy bình thường. Thứ tự các việc cũng phải được tính toán có chủ đích: tác vụ kiểm tra đơn hàng phải chạy trước tác vụ gửi email nhắc nhở, để hệ thống không gửi thư nhắc nhầm cho một người vừa mới thanh toán xong.
Một câu chuyện tương tự xảy ra với dịch vụ bộ nhớ đệm Upstash Redis: khi tích hợp qua cổng đối tác lưu trữ, tên biến môi trường tự động thay đổi so với tài liệu gốc, buộc lớp mã nguồn kết nối phải hỗ trợ song song cả hai bộ định danh và tự động dự phòng về bộ nhớ trong để không làm gián đoạn hệ thống.
Một giới hạn đếm được không làm sập hệ thống của bạn ngay lập tức, nhưng nó ép bạn phải từ bỏ thói quen viết mã tùy hứng để thiết lập một kỷ luật điều phối tập trung.
2. Trần dùng chung: Hai luồng việc tranh nhau một mẫu số
Loại trần thứ hai phức tạp hơn vì nó không nằm ở số lượng file, mà nằm ở sự xung đột giữa các luồng dữ liệu khác nhau trên cùng một hạn ngạch.
Dịch vụ gửi thư Resend ở gói miễn phí cấp cho bạn một định mức 200 email mỗi ngày. Con số đó trông rất thoải mái nếu bạn chỉ có vài người đăng ký tài khoản mỗi ngày.
Nhưng vấn đề nằm ở chỗ: con số 200 đó là mẫu số dùng chung cho mọi loại thư mà hệ thống phát ra.
Hệ thống của bạn có hai nhóm thư hoàn toàn khác nhau:
- Nhóm thư giao dịch: email kích hoạt tài khoản, liên kết đặt lại mật khẩu, biên lai mua hàng. Đây là những bức thư sống còn, khách hàng bấm nút là phải nhận được ngay trong vòng vài giây.
- Nhóm thư thông báo: email giới thiệu bài viết mới, thư nhắc nhở khóa học, thông báo cập nhật tài liệu. Đây là những bức thư gửi theo lô lớn đến danh sách người đăng ký.
Nếu bạn hẹn giờ cho hệ thống tự động gửi bài viết mới cho 200 người vào 9 giờ sáng, toàn bộ hạn mức miễn phí của ngày hôm đó sẽ cạn sạch chỉ sau vài phút.
Hậu quả là: một khách hàng mới đăng ký tài khoản vào lúc 10 giờ sáng sẽ không thể nhận được email kích hoạt. Khách hàng bấm quên mật khẩu vào buổi chiều sẽ bị chặn lại bởi lỗi vượt quá hạn mức ngày.
Để giải quyết xung đột này mà chưa cần nâng lên gói trả phí, giải pháp kỹ thuật là đặt trần cứng cho nhóm thư thông báo thấp hơn hạn mức của nhà cung cấp.
Trong hệ thống của tôi, hạn mức gửi chiến dịch tự động luôn bị khóa chặt ở mức tối đa 190 thư mỗi ngày. Mười bức thư còn lại được giữ lại làm vùng đệm an toàn tuyệt đối cho các thư giao dịch phát sinh bất ngờ.
Hiểu về trần dùng chung giúp bạn luôn ý thức phân loại mức độ ưu tiên của dữ liệu: đừng bao giờ để một luồng thông tin quảng bá gián tiếp làm tắc nghẽn trải nghiệm của những khách hàng đang thực sự giao dịch.
3. Trần im lặng: Thứ đắt nhất là thứ không báo lỗi
Trong các loại giới hạn, trần im lặng là thứ nguy hiểm nhất, tốn nhiều thời gian gỡ lỗi nhất và gây thiệt hại ngầm lớn nhất cho một sản phẩm đang chạy.
Một lỗi hiển thị rõ ràng trên màn hình (như mã lỗi 500 hay thông báo hết hạn ngạch) là một điều may mắn: bạn biết nó hỏng ở đâu, vào lúc nào và sửa ngay lập tức. Nhưng một hệ thống âm thầm trả về kết quả sai mà vẫn báo trạng thái thành công 200 là một cơn ác mộng.
Đó chính xác là cơ chế phân trang mặc định của tầng API PostgREST trên Supabase: mọi câu lệnh truy vấn đọc dữ liệu đều bị tự động cắt cụt ở ngưỡng tối đa 1.000 dòng mà không hề có bất kỳ cảnh báo nào.
Dù bạn viết lệnh yêu cầu lấy 10.000 dòng hay một câu truy vấn không hề đặt giới hạn, cơ sở dữ liệu vẫn chỉ trả về đúng 1.000 dòng đầu tiên.
Điều này dẫn đến những tình huống trớ trêu trong thực tế:
- Khi danh sách người nhận email vượt qua mốc 1.000 dòng, bảng thống kê quản trị đột nhiên hiển thị hàng trăm người "chưa nhận được thư", đơn giản vì 1.000 dòng mới nhất che mất toàn bộ lịch sử gửi thư cũ.
- Một phễu đo lường sự kiện người dùng tưởng như bị sụt giảm chuyển đổi nghiêm trọng, trong khi thực tế là hệ thống chỉ đang phân tích 1.000 sự kiện gần nhất trong tổng số gần 10.000 sự kiện đã diễn ra.
Hệ thống không hề sập, mã nguồn không có một dòng lỗi, nhưng mọi quyết định kinh doanh bạn đưa ra đều dựa trên những lát cắt dữ liệu bị khiếm khuyết.
Cách duy nhất để vô hiệu hóa trần im lặng là xây dựng một lớp đọc dữ liệu phân trang bắt buộc cho toàn bộ hệ thống: chia nhỏ mọi yêu cầu đọc thành các trang 1.000 dòng nối tiếp nhau, duyệt liên tục cho đến khi hết dữ liệu thực tế, và luôn kèm theo khóa sắp xếp duy nhất để các dòng không bị lặp lại hoặc bỏ sót khi chuyển trang.
4. Trần không công bố kích thước: Vận hành theo chu kỳ 5 tiếng
Bên cạnh hạ tầng máy chủ, có một chiếc trần khác định hình nhịp làm việc hàng ngày của bạn với AI coding agent: hạn mức chu kỳ sử dụng của mô hình ngôn ngữ lớn.
Như tôi từng phân tích khi bàn về sự khác biệt giữa thuê bao cố định và trả phí theo token API, các gói thuê bao AI đều áp dụng cơ chế làm mới hạn ngạch sau mỗi 5 tiếng kèm theo một trần ngân sách tuần, và không nhà cung cấp nào công bố chính xác mẫu số dung lượng của bạn là bao nhiêu.
Vì bạn không biết dung lượng tuyệt đối của chiếc túi, cách duy nhất để tối ưu hiệu suất là quy hoạch thời gian để khai thác tối đa số chu kỳ làm mới trong ngày.
Một đặc tính quan trọng của chu kỳ 5 tiếng là: đồng hồ chỉ bắt đầu đếm ngược từ thời điểm bạn gửi câu lệnh đầu tiên cho mô hình.
Nếu bạn bắt đầu ngày làm việc vào lúc 8 giờ sáng, trong suốt khung giờ hành chính bạn chỉ có đúng hai chu kỳ sử dụng (chu kỳ thứ nhất từ 8h đến 13h, và chu kỳ thứ hai từ 13h đến 18h). Toàn bộ khối lượng công việc lớn dồn vào hai lần reset này rất dễ làm cạn hạn mức giữa chừng, trong khi ngân sách tuần bị lãng phí vì không được phân bổ đều đặn.
Giải pháp kỹ thuật của tôi là thiết lập một tác vụ tự động đánh thức chu kỳ từ 5 giờ sáng.
Khi hệ thống tự kích hoạt một lệnh nhỏ vào lúc 5h sáng, các mốc làm mới tự nhiên trong ngày sẽ rơi vào lúc 10h và 15h. Nhờ đó, bạn có trọn vẹn ba chu kỳ làm việc đầy đủ trong giờ hành chính, và có thể mở rộng lên bốn chu kỳ nếu tiếp tục làm việc vào buổi tối. Thay vì bị động chờ đợi mô hình hồi phục hạn mức, việc xếp lịch thông minh giúp bạn nhân đôi năng suất xử lý mà không tốn thêm một đồng chi phí nào.
<!-- CUA-BAN-HANG-1 -->
📥 Tải miễn phí
Bộ Khung Repo Cho AI Agent
Khung quyết định: Lúc nào cái trần bắt đầu tính tiền của bạn?
Xếp chồng các dịch vụ miễn phí như Vercel, Supabase, Resend, Upstash và PayOS mang lại cho bạn một điểm tựa hoàn hảo để đưa ý tưởng ra thị trường với chi phí vốn bằng không.
Nhưng câu hỏi quan trọng nhất của bài toán hạ tầng là: khi nào bạn thực sự nên trả tiền để nâng gói?
Câu trả lời không nằm ở khoảnh khắc bạn chạm vào con số giới hạn trên bảng tính. Câu trả lời nằm ở khoảnh khắc chiếc trần đó bắt đầu làm thay đổi quyết định vận hành của bạn.
Thực tế trên hệ thống của tôi cho thấy: danh sách người đăng ký nhận tin đã vượt qua trần của gói gửi thư miễn phí từ lâu, nhưng tôi vẫn chưa nâng gói Pro. Lý do rất đơn giản: tôi chưa có kế hoạch mở rộng các chiến dịch tiếp thị hàng loạt ở giai đoạn này. Khi nhu cầu thực tế chưa đòi hỏi, việc vượt qua một con số lý thuyết chưa thể ép bạn phải rút ví.
Bạn chỉ nên nâng gói khi đối mặt với ba ranh giới rõ ràng sau:
Thứ nhất, chi phí thời gian viết code lách trần đắt hơn tiền thuê bao hàng tháng. Nếu bạn phải bỏ ra nhiều ngày làm việc chỉ để dựng các hệ thống hàng đợi phức tạp nhằm né tránh giới hạn của gói khởi đầu, trong khi chi phí nâng cấp chỉ ở mức 20 hay 25 đô la mỗi tháng, bạn đang đánh đổi tài nguyên quý giá nhất của mình cho một khoản tiết kiệm không đáng có.
Thứ hai, sản phẩm bước vào giai đoạn thương mại hóa ổn định. Khi hệ thống đã có dòng tiền từ khách hàng trả phí, việc duy trì một hạ tầng chuyên nghiệp để cơ sở dữ liệu không bị tự động tạm dừng sau 7 ngày không hoạt động là điều kiện tiên quyết để bảo vệ uy tín thương hiệu.
Thứ ba, chạm vào các giới hạn cứng không thể khắc phục bằng giải pháp phần mềm. Đó là khi thời gian chạy hàm máy chủ vượt quá ngưỡng 10 giây cho các tác vụ tính toán phức tạp, hoặc khi dung lượng lưu trữ vượt quá mức 500 MB của cơ sở dữ liệu khởi đầu.
Điều tôi nhận ra
Hành trình xây dựng và vận hành một sản phẩm thật trên nền hạ tầng tinh gọn giúp tôi rút ra ba bài học cốt lõi:
Thứ nhất, gói miễn phí không phải là một bữa ăn miễn phí hoàn toàn: nó mua cho bạn thời gian để thử nghiệm ý tưởng, nhưng nó đòi hỏi bạn phải trả bằng kỷ luật thiết kế và sự thấu hiểu sâu sắc về kiến trúc hệ thống.
Thứ hai, đừng đợi đến khi hệ thống phát sinh lỗi mới bắt đầu rà soát; hãy luôn cảnh giác cao độ với những chiếc trần im lặng cắt xén dữ liệu mà không đưa ra bất kỳ cảnh báo nào.
Thứ ba, nâng cấp hạ tầng là một quyết định đầu tư thuần túy: hãy bắt đầu từ mức 0 đồng để rèn luyện sự tinh gọn, và chỉ nâng gói khi giá trị kinh doanh tạo ra vượt xa chi phí thuê bao hàng tháng của nhà cung cấp.
Trước khi khép lại, tôi muốn nói rõ về phạm vi của những con số trong bài:
Các thông tin về biểu giá và hạn mức kỹ thuật của năm dịch vụ hạ tầng được tra cứu trực tiếp từ các trang tài liệu chính thức vào ngày 2026-08-26. Các câu chuyện về sự cố và giải pháp điều phối mã nguồn là trải nghiệm thực tế trên hệ thống website của tôi. Bài viết này hoàn toàn không chứa bất kỳ số liệu doanh thu, quy mô người dùng hay thông tin bảo mật nội bộ nào.
Hiểu rõ bản chất của từng loại trần hạ tầng giúp bạn tự tin làm chủ công nghệ: tận dụng tối đa sức mạnh của các gói khởi đầu, bảo vệ dữ liệu luôn chính xác, và đưa ra quyết định nâng cấp đúng thời điểm để sản phẩm phát triển bền bỉ.
<!-- CUA-BAN-HANG-2 -->
Cấu trúc 11 bài học về bẫy hạ tầng và các nguyên tắc vận hành hệ thống cùng AI agent được tôi ghi lại chi tiết trong bộ Token Efficient Vibe Coding Kit để bạn tránh những lỗi ngầm tương tự.
