AI làm ứng dụng nhanh hơn, nhưng nguy hiểm nhất là cảm giác “xong rồi”
Với AI, một ứng dụng nhiều người dùng có thể thành hình rất nhanh. Tạo phòng được, người dùng tham gia được, đăng nội dung được, bình chọn được. Não lập tức nói:
Xong.
Máy chủ trả lời:
Bạn mới thử với một người thôi.
Câu hỏi thật sự là: nếu 100 người thao tác cùng lúc thì sao? Nếu dữ liệu đã ghi thành công nhưng phản hồi thành công bị mất thì sao? Nếu phiếu cuối cùng trùng đúng thời hạn? Nếu thông báo thanh toán tới hai lần? Nếu tất cả cùng kết nối lại sau sự cố?
Một lần review code cho ứng dụng web nhiều người dùng nhỏ đã mở rộng thành 324 trường hợp kiểm thử. Điều đó không có nghĩa là tìm thấy 324 lỗi. Cả 324 trường hợp lúc đó vẫn chưa chạy. Đó là kế hoạch kiểm thử, không phải chứng nhận đạt.
1. Không chỉ DDoS mới làm ứng dụng nghẹt
Cloudflare có bảo vệ DDoS tự động trên mọi gói, nhưng vẫn khuyến nghị các biện pháp cấp ứng dụng như rate limiting vì tấn công lớn vẫn có thể ảnh hưởng tới ứng dụng.[1]
Với dự án nhỏ, lưu lượng hợp lệ có thể là vấn đề đầu tiên.
Nếu client kiểm tra trạng thái mỗi 3 giây:
| Thiết bị đồng thời | Lần kiểm tra mỗi giờ |
|---|---|
| 10 | 12.000 |
| 30 | 36.000 |
| 100 | 120.000 |
| 1.000 | 1.200.000 |
Đây không phải dự báo sức chứa thực tế. Backoff và cache có thể giảm; bài đăng, ảnh, inbox, nhiều tab và tác vụ định kỳ có thể tăng.
Tính đến ngày 5/10/2026, Workers Free ghi 100.000 request/ngày. D1 Free ghi 5 triệu hàng đọc/ngày, 100.000 hàng ghi/ngày, 500 MB mỗi database và 50 query mỗi lần Worker được gọi.[2][3] Một database D1 xử lý query từng cái một; quá nhiều truy cập đồng thời sẽ xếp hàng và có thể dẫn tới lỗi quá tải.[3]
Vì vậy không chỉ “một triệu kẻ tấn công” mới đáng sợ.
100 người dùng bình thường cùng chơi vui vẻ cũng có thể là một bài load test.
2. Vì sao danh sách lên tới 324 mục
Nó bao phủ 16 nhóm: đầu vào và lạm dụng, dung lượng, đồng thời và khôi phục, tác vụ định kỳ, phòng và quyền, ảnh, văn bản, bình chọn, thời hạn, mở kết quả, phòng công khai, kết nối giữ lâu, thiết bị và reconnect, tích hợp, thanh toán, triển khai và giám sát.
Không cần làm mọi thứ cùng lúc. Hãy ưu tiên.
3. 23 điểm nên đánh trước khi mở công khai
- Request bị từ chối có vẫn đi vào xử lý database tốn kém không?
- Bộ đếm usage nội bộ có thực sự tính mọi đường xử lý nặng không?
- Rate limit có giữ được qua restart và nhiều instance không?
- Polling “không có thay đổi” có vẫn đọc nhiều dữ liệu không?
- Một chỗ ngồi có mở vô hạn kết nối giữ lâu không?
- HTTP và kết nối giữ lâu có cùng giới hạn không?
- Emergency stop có dừng client đang kết nối không?
- Scheduler chậm có làm thao tác sau deadline vẫn được nhận không?
- Một phần ghi thất bại nhưng phòng vẫn chuyển bước không?
- Job sửa chữa chạy lại có cộng thống kê hai lần không?
- Lượt bắt đầu có bị trừ trước khi game thực sự được tạo không?
- Retry có biến một câu trả lời thành hai không?
- Biến thể tên nhìn giống nhau có vượt qua kiểm tra duy nhất không?
- Hai người có cùng lấy được chỗ cuối cùng không?
- Job định kỳ có tích lũy nhanh hơn tốc độ xử lý không?
- Có đo toàn bộ database và index, không chỉ ảnh không?
- Người khác có thể chiếm danh tính từ thiết bị bị mất không?
- Loại ảnh, kích thước, metadata và vị trí có được xử lý an toàn không?
- Lịch sử dài có làm mỗi màn hình ngày càng đắt không?
- Reconnect đồng loạt có gây sự cố lần hai không?
- Đã kiểm thử thanh toán trùng, chậm, lỗi, hủy và khôi phục chưa?
- Có nhầm test local đạt với production đạt không?
- Database chết thì hệ thống giám sát có chết theo không?
4. Lỗi thích đi theo tổ hợp
Một kịch bản giá trị cao:
100 người vote → 20 người refresh → 10 người mất mạng → một số write thành công nhưng response mất → retry.
Sau đó xem có vote trùng, vote trễ, giao diện quay về state cũ hay cùng thao tác chạy hai lần không.
OWASP cũng coi concurrent session, input bất thường và xử lý lỗi là các chủ đề kiểm thử riêng.[4]
5. “Đã ghi” và “người dùng nhận OK” là hai việc khác nhau
Server có thể ghi thành công nhưng phản hồi mạng bị mất.
Người dùng tưởng lỗi và bấm lại.
Nếu không có operation ID hoặc cơ chế chống trùng, có thể tạo hai câu trả lời, hai phòng, hai phiếu, hai thông báo hoặc hai lần tính tiền.
Retry cần được thiết kế.
6. Load test phải tăng dần
Trong môi trường bạn kiểm soát: 10 → 30 → 100 client.
Sau đó thay hình dạng lưu lượng: một phòng đông, nhiều phòng, join cùng lúc, phiếu cuối cùng cùng lúc, reconnect hàng loạt, job định kỳ trùng thời điểm và mô phỏng lỗi lưu trữ.
Không gửi lưu lượng lớn có chủ ý tới hệ thống không được phép kiểm thử. Đặt ngân sách và điều kiện dừng trước.
7. “Không sập” chưa đủ để đạt
Có thể đặt mục tiêu ban đầu: 95% request bình thường dưới 1 giây, 99% dưới 3 giây, lỗi 5xx ngoài dự kiến dưới 0,1%.
Nhưng các mục sau nên bằng 0:
- lộ dữ liệu người khác;
- hành động không có quyền;
- tính điểm trùng;
- mất dữ liệu đã xác nhận;
- tính tiền hai lần.
8. Thiết kế 9/10, bằng chứng chạy thật 0/10 là có thể
Danh sách 324 mục và 23 rủi ro ưu tiên có thể rất tốt.
Nhưng trước khi chạy, bằng chứng thực tế vẫn là 0.
Đó không phải thất bại. Dự án đã đi từ “không biết thử gì” sang “biết chính xác nên thử làm hỏng ở đâu”.
9. Sau đó thứ chạm giới hạn trước có thể là quota AI
Nếu cả ngày để AI đọc repository lớn, triển khai, sửa, review rồi lặp lại, quota AI có thể cạn trước server.
Tính đến 5/10/2026, Claude Max 20x có giá 200 USD/tháng trên web. “20x” là dung lượng mỗi session so với Pro. Session reset mỗi 5 giờ, nhưng Max cũng có giới hạn hàng tuần dùng chung cho tất cả model.[5]
20x không có nghĩa là vô hạn.
Mức tiêu thụ phụ thuộc model, context và tác vụ; Settings > Usage là nơi nên kiểm tra.
10. “Fable đắt” cũng đúng khi nhìn vào số
Trên Max, Fable 5 và 5.1 được hỗ trợ, nhưng Fable có thể dùng tối đa 50% giới hạn tuần và Anthropic nói nó tiêu hao hạn mức nhanh hơn các model Claude khác.[6]
| Model | Input / 1M token | Output / 1M token |
|---|---|---|
| Sonnet 5.5 | $2 | $10 |
| Opus 5.5 | $4 | $20 |
| Fable 5.1 | $10 | $50 |
Giá input và output của Fable 5.1 gấp 2,5 lần Opus 5.5. Cache read rẻ hơn giúp giảm chi phí so với Fable 5, nhưng mức giá tuyệt đối vẫn cao.[6][7][8]
Không thể đổi trực tiếp giá API thành phút quota Max, nhưng hướng chung vẫn rõ: chạy model nặng lâu sẽ tốn.
11. Không cần dùng xe cẩu cho mọi con ốc
Sonnet 5.5: sửa thường ngày, bug đã hiểu, chỉnh sửa lặp lại, việc có phạm vi rõ.
Opus 5.5: nguyên nhân chưa rõ, thay đổi kiến trúc, review nhiều file, quyết định quan trọng trước khi release.
Fable 5.1: việc khó nhất khi năng lực bổ sung đáng với chi phí hoặc quota cao hơn.
Đó không phải bảng xếp hạng. Đó là quản lý chi phí theo nhiệm vụ.
12. AI không xóa bottleneck; AI chuyển bottleneck
Trước đây: ý tưởng → vài tuần code → test.
Bây giờ: ý tưởng → triển khai nhanh → test, vận hành, quota server và quota AI cùng xuất hiện.
“Tôi làm app trong một ngày” có thể đúng.
Câu chính xác hơn:
“Trong một ngày, tôi đã tới giai đoạn có thể bắt đầu thử phá nó một cách nghiêm túc.”
Đó mới là lúc chuẩn bị phát hành thật sự bắt đầu.
- Cloudflare DDoS developers.cloudflare.com
- Cloudflare Workers developers.cloudflare.com
- Cloudflare D1 developers.cloudflare.com
- OWASP WSTG wstg.owasp.org
- Anthropic Max support.claude.com
- Anthropic Fable support.claude.com
- Opus 5.5 anthropic.com
- Sonnet 5.5 anthropic.com
