Giới hạn tốc độ cho API công khai: quota thực tế và quy trình khóa

Vấn đề mà giới hạn tốc độ thực sự giải quyết

Giới hạn tốc độ cho API công khai không phải để trừng phạt người dùng. Nó là van an toàn giữ dịch vụ của bạn hoạt động khi traffic trở nên bất thường, dù sự bất thường đó là có chủ ý hay chỉ do lỗi client.

"Lạm dụng" thường ban đầu trông bình thường: một scraper dò mọi endpoint để sao chép dữ liệu, thử đăng nhập theo kiểu brute-force, tấn công token vào các route xác thực, hoặc một client bị lỗi lặp lại cùng một request không ngừng sau timeout. Đôi khi không ai tấn công bạn cả — một bản cập nhật app di động mang theo quy tắc cache sai và đột nhiên mọi thiết bị đều poll API mỗi giây.

Mục tiêu đơn giản: bảo vệ uptime và kiểm soát chi phí mà không cản trở người dùng thực hiện công việc bình thường. Nếu backend của bạn tính phí theo metering (compute, database, email/SMS, gọi AI), một tác nhân gây ồn có thể khiến hóa đơn tăng nhanh.

Tuy nhiên, chỉ có rate limiting thôi chưa đủ. Nếu thiếu giám sát và phản hồi lỗi rõ ràng, bạn sẽ có những lỗi im lặng, khách hàng bối rối và ticket hỗ trợ nghe như "API của bạn bị sập" trong khi thực tế nó đang throttle.

Một bộ bảo vệ đầy đủ thường gồm vài phần riêng biệt:

• Rate limits: giới hạn cửa sổ ngắn (theo giây/phút) để chặn các đột biến.
• Quotas: hạn mức cửa sổ dài hơn (theo ngày/tháng) để giữ usage dự đoán được.
• Lockouts: chặn tạm thời cho những mẫu hành vi rõ ràng là lạm dụng.
• Exceptions: allowlist cho tích hợp tin cậy, công cụ nội bộ hoặc khách VIP.

Nếu bạn xây dựng backend API trên một nền tảng như AppMaster, những quy tắc này vẫn quan trọng. Ngay cả với mã được tạo sạch sẽ, bạn vẫn cần các mặc định bảo vệ để một client xấu không kéo cả dịch vụ xuống.

Thuật ngữ chính: rate limit, quota, throttling và lockout

Các thuật ngữ này hay bị lẫn lộn, nhưng mỗi cái giải quyết vấn đề khác nhau và cảm nhận của người dùng cũng khác.

Rate limit, quota và concurrency: mỗi cái nghĩa là gì

Một rate limit là giới hạn tốc độ: số request một client có thể gửi trong cửa sổ ngắn (theo giây, theo phút). Một quota là ngân sách: tổng sử dụng trong khoảng dài hơn (theo ngày, theo tháng). Concurrency limit giới hạn số request đang xử lý đồng thời, hữu ích cho các endpoint tốn kém ngay cả khi tần suất request trông bình thường.

Nơi bạn gắn giới hạn cũng quan trọng:

• Per IP: đơn giản, nhưng trừng phạt mạng chia sẻ (văn phòng, trường học, nhà mạng di động).
• Per user: tốt cho ứng dụng có đăng nhập, nhưng phụ thuộc vào định danh đáng tin cậy.
• Per API key: phổ biến với API công khai, rõ ràng chủ sở hữu và dễ thông báo.
• Per endpoint: hữu ích khi một route nặng hơn nhiều so với phần còn lại.

Throttling vs blocking, và lockouts nằm ở đâu

Soft throttling làm chậm client (delay, giảm burst) để họ có thể khôi phục mà không phá vỡ workflow. Hard blocking từ chối ngay lập tức, thường trả HTTP 429.

Lockout mạnh hơn một 429 thông thường. 429 nói "thử lại sớm". Lockout nói "dừng lại cho đến khi điều kiện được đáp ứng", chẳng hạn khoảng thời gian cooldown, xem xét bằng tay, hoặc reset key. Dùng lockout cho tín hiệu lạm dụng rõ ràng (credential stuffing, scraping hung hãn, auth sai lặp lại), không phải cho các đột biến traffic bình thường.

Khi xây API với công cụ như AppMaster, coi các điều khiển này riêng biệt: giới hạn cửa sổ ngắn cho burst, quota dài hơn cho chi phí, và lockout chỉ cho hành vi xấu lặp lại.

Chọn giới hạn thực tế mà không phải đoán bừa

Giới hạn tốt bắt đầu với một mục tiêu: bảo vệ backend đồng thời cho phép người dùng bình thường hoàn thành công việc. Bạn không cần số hoàn hảo ngay ngày đầu — cần một baseline an toàn và cách điều chỉnh.

Một điểm khởi đầu đơn giản là giới hạn theo API key phù hợp loại API bạn chạy:

• Lưu lượng thấp: 60–300 request/phút/key
• Lưu lượng trung bình: 600–1.500 request/phút/key
• Lưu lượng cao: 3.000–10.000 request/phút/key

Rồi phân chia giới hạn theo loại endpoint. Các thao tác đọc thường rẻ hơn và có thể có giới hạn cao hơn. Các thao tác ghi thay đổi dữ liệu, thường kích hoạt thêm logic và nên chặt hơn. Một mô hình phổ biến: 1.000/phút cho GET nhưng 100–300/phút cho POST/PUT/DELETE.

Xác định các endpoint tốn kém và xử lý chúng riêng. Tìm kiếm, tạo báo cáo, xuất dữ liệu, upload file, và bất cứ thứ gì chạm nhiều bảng hoặc chạy logic nặng nên có bucket nhỏ hơn ngay cả khi phần còn lại của API hào phóng. Nếu backend của bạn dùng visual workflows (ví dụ Business Process flows), mỗi bước bổ sung là công việc thực sự nhân lên dưới tải.

Chuẩn bị cho burst bằng hai cửa sổ: một cửa sổ ngắn để hấp thụ spike nhanh, và một cửa sổ dài hơn để kiểm soát sử dụng kéo dài. Kết hợp phổ biến là 10 giây + 10 phút. Điều này giúp người dùng thật sự click nhanh, nhưng không cho scraper tốc độ vô hạn.

Cuối cùng, quyết định điều gì xảy ra khi client vượt quá giới hạn. Phần lớn API công khai trả HTTP 429 với thời gian retry rõ ràng. Nếu công việc có thể trì hoãn (như export), cân nhắc đưa vào hàng đợi thay vì chặn cứng để người dùng thực sự vẫn có kết quả.

Thiết kế quota theo key sao cho công bằng

Quota theo key thường công bằng nhất vì phản ánh cách khách hàng dùng dịch vụ: một tài khoản, một API key, trách nhiệm rõ ràng. Giới hạn theo IP vẫn có ích, nhưng thường phạt người vô tội.

IP chia sẻ là lý do lớn. Cả một văn phòng có thể ra ngoài qua một IP công cộng, và nhà mạng di động có thể gom hàng nghìn thiết bị sau một vài IP. Nếu bạn dựa vào giới hạn per-IP, một người dùng ồn ào có thể làm chậm cả nhóm. Quota theo key tránh điều đó, và bạn có thể giữ giới hạn IP nhẹ như backstop cho các flood rõ rệt.

Để quota hợp lý, liên kết chúng với hạng khách hàng mà không bẫy người dùng mới. Key free hoặc trial nên đủ để test thực tế, nhưng không đủ scale để gây hại. Mẫu đơn giản: burst hào phóng, rate duy trì khiêm tốn, và quota ngày phù hợp với gói.

Chính sách theo key có thể công bằng và dự đoán:

• Cho phép burst ngắn (page load, import batch), sau đó áp rate ổn định.
• Thêm cap hàng ngày cho mỗi key để hạn chế scraping và vòng lặp vô tận.
• Tăng giới hạn theo gói, nhưng giữ cấu trúc giống nhau để hành vi nhất quán.
• Dùng cap thấp hơn cho key mới tạo cho tới khi họ có lịch sử tốt.
• Giữ một giới hạn per-IP nhỏ để bắt các flood hiển nhiên và client cấu hình sai.

Để ngăn chia sẻ key và đăng ký tự động, bạn không cần giám sát nặng. Bắt đầu với kiểm tra đơn giản như thay đổi geo bất thường, quá nhiều IP khác nhau trong một giờ cho cùng một key, hoặc nhiều key mới tạo từ cùng nguồn. Flag và làm chậm trước; khóa chỉ sau nhiều tín hiệu lặp lại.

Traffic ẩn danh là nơi nên áp caps chặt hơn. Nếu bạn cung cấp key thử nghiệm, rate-limit chặt và yêu cầu bước xác thực cơ bản trước khi nâng giới hạn. Nếu API của bạn phục vụ một form công khai, xem xét một endpoint ẩn danh riêng với quota riêng để phần còn lại của backend được bảo vệ.

Nếu bạn xây API bằng AppMaster, logic per-key dễ duy trì nhất bởi auth, business rules và xử lý phản hồi sống ở cùng một chỗ.

Phản hồi thân thiện với client và headers (để họ có thể phục hồi)

Rate limiting chỉ hiệu quả lâu dài nếu client hiểu chuyện gì đã xảy ra và làm gì tiếp theo. Hướng tới phản hồi dự đoán: cùng status code, cùng trường, cùng ý nghĩa trên mọi endpoint.

Khi client chạm limit, trả HTTP 429 (Too Many Requests) với thông điệp rõ ràng và thời gian chờ cụ thể. Bước nhanh nhất là thêm Retry-After, vì ngay cả client đơn giản cũng có thể pause đúng.

Một tập header nhỏ làm giới hạn tự giải thích. Giữ tên nhất quán và bao gồm chúng cả trên response thành công (để client tự điều tiết) và response 429 (để client phục hồi):

• Retry-After: số giây cần chờ trước khi thử lại
• X-RateLimit-Limit: số request được phép trong cửa sổ hiện tại
• X-RateLimit-Remaining: số request còn lại trong cửa sổ
• X-RateLimit-Reset: khi cửa sổ reset (epoch seconds hoặc thời gian ISO)
• X-RateLimit-Policy: chuỗi ngắn như "60 requests per 60s"

Làm thân error body cấu trúc như success responses. Một mẫu phổ biến là object lỗi có code ổn định, message thân thiện, và gợi ý phục hồi.

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry after 12 seconds.",
    "retry_after_seconds": 12,
    "limit": 60,
    "remaining": 0,
    "reset_at": "2026-01-25T12:34:56Z"
  }
}

Hãy chỉ dẫn client cách back off khi thấy 429. Exponential backoff là mặc định tốt: chờ 1s, rồi 2s, rồi 4s, và cap (ví dụ 30–60 giây). Đồng thời nêu rõ khi nào nên ngừng retry.

Tránh bất ngờ gần quota. Khi một key gần đạt cap (ví dụ 80–90% dùng), thêm trường cảnh báo hoặc header để client giảm tốc trước khi bắt đầu fail. Việc này càng quan trọng khi một script có thể gọi nhiều route nhanh và đốt ngân sách nhanh hơn dự đoán.

Kế hoạch rollout từng bước cho giới hạn và quota

Rollout hiệu quả nhất khi bạn coi giới hạn như hành vi sản phẩm, không phải một rule firewall một lần. Mục tiêu không đổi: bảo vệ backend trong khi giữ khách hàng bình thường di chuyển.

Bắt đầu với kiểm kê nhanh. Liệt kê mọi endpoint, rồi đánh dấu từng endpoint theo chi phí (CPU, database, gọi bên thứ ba) và rủi ro (login, reset mật khẩu, search, upload). Điều này ngăn bạn áp một giới hạn cứng cho mọi thứ.

Thứ tự rollout thường tránh bất ngờ:

• Gắn tag endpoint theo chi phí và rủi ro, quyết định cái nào cần rule chặt hơn (login, export lớn).
• Chọn khóa định danh theo thứ tự ưu tiên: API key trước, rồi user id, IP chỉ khi cần.
• Thêm giới hạn cửa sổ ngắn (per 10s hoặc per minute) để dừng burst và script.
• Thêm quota cửa sổ dài hơn (per hour hoặc per day) để giới hạn dùng kéo dài.
• Thêm allowlist cho hệ thống tin cậy và công cụ nội bộ để ops không bị chặn.

Giữ bản phát hành đầu thận trọng. Dễ nới lỏng sau hơn là mở khoá người dùng giận dữ.

Giám sát và tinh chỉnh, rồi version chính sách. Theo dõi bao nhiêu request bị giới hạn, endpoint nào kích hoạt, và bao nhiêu key bị ảnh hưởng. Khi bạn thay đổi số, coi đó là thay đổi API: document, triển khai dần, và giữ rule cũ–mới tách biệt để rollback nhanh.

Nếu xây API với AppMaster, lên kế hoạch những rule này cùng lúc với endpoint và business logic để giới hạn khớp với chi phí thực tế của mỗi workflow.

Luồng khóa (lockout) dừng lạm dụng mà không gây ồn ào

Lockout là dây an toàn. Nó nên dừng lạm dụng rõ rệt nhanh chóng, nhưng vẫn cho người dùng bình thường con đường phục hồi khi có sự cố.

Cách tiếp cận bình tĩnh là hình phạt lũy tiến. Giả sử client có thể cấu hình sai chứ không phải luôn luôn ác ý, và chỉ tăng mức trừng phạt khi cùng mẫu xuất hiện lặp lại.

Thang lũy tiến đơn giản

Dùng một tập bước nhỏ dễ giải thích và dễ triển khai:

• Cảnh báo: thông báo client họ sắp chạm giới hạn, và khi nó reset.
• Làm chậm: thêm delay ngắn hoặc thắt giới hạn theo giây cho key đó.
• Khóa tạm thời: chặn trong vài phút (không phải vài giờ) với thời gian mở khoá chính xác.
• Khóa lâu hơn: chỉ sau các đợt burst lặp lại qua nhiều cửa sổ.
• Xem xét bằng tay: cho các mẫu có vẻ cố ý hoặc lặp lại.

Chọn đối tượng bị khóa quan trọng. Per API key thường công bằng vì nhắm trực tiếp tới caller, không phải mọi người sau mạng chia sẻ. Per account hữu ích khi user xoay key. Per IP giúp với traffic ẩn danh, nhưng gây false positive cho NAT, văn phòng và nhà mạng. Khi lạm dụng nghiêm trọng, kết hợp nhiều tín hiệu (ví dụ khóa key và yêu cầu kiểm tra thêm cho IP đó), nhưng giữ blast radius nhỏ.

Thiết kế lockout theo thời gian với luật đơn giản: "bị chặn đến 14:05 UTC" và "reset sau 30 phút hành vi tốt". Tránh cấm vĩnh viễn cho hệ thống tự động. Một client lỗi có thể loop và đốt giới hạn nhanh, nên thiết kế biện pháp giảm dần theo thời gian. Một khoảng thời gian duy trì ở mức thấp nên giảm cấp phạt.

Nếu bạn xây API trong AppMaster, thang này phù hợp với các bộ đếm lưu trữ cộng một Business Process quyết định allow, slow, hoặc block và ghi thời gian mở khoá cho key.

Với kẻ vi phạm lặp lại, giữ con đường xem xét bằng tay. Đừng cãi với người dùng. Yêu cầu request ID, timestamp và tên API key, rồi quyết định dựa trên bằng chứng.

Lỗi phổ biến gây false positives

False positives xảy ra khi phòng thủ chặn người dùng bình thường. Thường xảy ra khi rule quá đơn giản so với cách người ta thực sự dùng API.

Sai lầm kinh điển là một giới hạn toàn cục cho mọi thứ. Nếu bạn đối xử cùng một mức cho endpoint đọc rẻ và export tốn kém, bạn sẽ hoặc bảo vệ quá mức endpoint rẻ (làm phiền) hoặc bảo vệ không đủ endpoint tốn kém (nguy hiểm). Phân tách theo chi phí endpoint và làm nặng đường nặng hơn.

Giới hạn chỉ theo IP là bẫy khác. Nhiều người dùng thật chia sẻ một IP công cộng (văn phòng, trường học, nhà mạng). Một người dùng nặng có thể chặn mọi người và trông như outage ngẫu nhiên. Ưu tiên giới hạn theo API key trước, rồi dùng IP như tín hiệu thứ cấp.

Sự cố về chính hệ thống limiter cũng gây false positives. Nếu store của limiter chết, "fail closed" có thể làm sập toàn bộ API. "Fail open" lại mời spike làm backend sập. Chọn fallback rõ ràng: giữ một cap khẩn cấp nhỏ ở edge, và giảm tính năng dần trên các endpoint không quan trọng.

Xử lý phía client quan trọng hơn nhiều team nghĩ. Nếu bạn trả 429 chung chung không rõ, người dùng sẽ retry nhiều hơn và kích hoạt thêm block. Luôn gửi Retry-After, và giữ text lỗi cụ thể ("Too many requests for this key. Try again in 30 seconds.").

Vấn đề dễ tránh nhất là bí mật. Giới hạn ẩn cảm giác như bug khi khách hàng gặp tải production lần đầu. Chia sẻ chính sách đơn giản và giữ nó ổn định.

Checklist nhanh tránh false positives:

• Tách giới hạn cho endpoint rẻ và tốn kém
• Hạn chế chính theo API key, không chỉ theo IP
• Hành vi định nghĩa khi limiter không khả dụng
• 429 rõ ràng với Retry-After
• Giới hạn được document và thông báo trước khi thi hành

Nếu bạn xây API bằng AppMaster, điều này thường có nghĩa là đặt các cap khác nhau cho mỗi endpoint và trả payload lỗi nhất quán để client có thể back off mà không đoán mò.

Giám sát và alert thực sự hữu ích

Rate limiting chỉ hiệu quả nếu bạn thấy chuyện gì đang diễn ra real-time. Mục tiêu không phải bắt mọi spike mà là phát hiện những pattern có thể dẫn đến outage hoặc khách hàng giận.

Bắt đầu với tập tín hiệu nhỏ giải thích cả volume lẫn ý định:

• Requests per minute (tổng thể và per API key)
• 429 rate (request bị throttle) và 5xx rate (backend đang đau)
• Burst 401/403 lặp lại (key sai, credential stuffing, client cấu hình sai)
• Top endpoint theo volume và theo chi phí (query chậm, export nặng)
• Endpoint mới hoặc bất ngờ xuất hiện trong top 10

Để tách "traffic xấu" khỏi "chúng tôi vừa deploy", thêm bối cảnh vào dashboard: thời gian deploy, thay đổi feature flag, chiến dịch marketing. Nếu traffic tăng ngay sau release và tỷ lệ 429/5xx vẫn ổn, thường là growth, không phải abuse. Nếu tăng tập trung vào một key, một dải IP, hoặc một endpoint nặng, xử lý nghi ngờ.

Alert nên buồn tẻ. Dùng ngưỡng cộng cooldown để không bị paging mỗi phút cho cùng một sự kiện:

• 429 rate vượt X% trong 10 phút, thông báo một lần mỗi giờ
• 5xx vượt Y% trong 5 phút, gọi paging ngay
• Một key vượt quota Z% trong 15 phút, mở điều tra
• Burst 401/403 trên N/min, đánh dấu khả năng abuse

Khi alert nổ, giữ một note ngắn sự cố: thay đổi gì, bạn thấy gì (top key/endpoint), và bạn đã điều chỉnh gì (giới hạn, cache, block tạm). Qua thời gian, những note đó trở thành playbook thực sự.

Ví dụ: bạn ra mắt endpoint search mới và traffic tăng gấp đôi. Nếu hầu hết gọi tới endpoint đó trên nhiều key, tăng nhẹ quota per-key và tối ưu endpoint. Nếu một key gọi export liên tục làm tăng latency, cap riêng endpoint đó và liên hệ owner.

Checklist nhanh: kiểm tra trước và sau khi ra mắt

Một thiết lập tốt thường tẻ nhạt khi nó hoạt động. Checklist này bắt các vấn đề thường tạo false positives hoặc để lại lỗ hổng rõ rệt.

Trước khi phát hành endpoint mới

Chạy kiểm tra ở staging và lại ngay sau khi ra mắt:

• Identity: xác nhận limiter dựa trên đúng thứ (API key trước, user hoặc IP làm fallback), và key xoay không mang theo penalty cũ.
• Limits: đặt default per-key quota, sau đó điều chỉnh theo chi phí endpoint (đọc rẻ vs ghi tốn kém) và burst dự kiến.
• Responses: trả status và thông tin phục hồi rõ ràng (thời gian retry, ngân sách còn lại, mã lỗi ổn định).
• Logs: ghi lại ai bị giới hạn (key/user/IP), route nào, rule nào kích hoạt, và request ID cho support.
• Bypass: giữ allowlist khẩn cấp cho monitor và tích hợp tin cậy.

Nếu bạn build trên AppMaster, coi mỗi endpoint mới như quyết định tầng chi phí: lookup đơn giản có thể hào phóng, còn bất cứ thứ gì kích hoạt business logic nặng nên bắt đầu chặt hơn.

Khi sự cố xảy ra (lạm dụng hoặc traffic đột ngột)

Bảo vệ backend trong khi cho người dùng thật phục hồi:

• Tạm thời nâng cap chỉ cho route ít rủi ro nhất (thường là read) và theo dõi error rate.
• Thêm allowlist ngắn cho khách hàng tốt trong lúc điều tra.
• Siết các route rủi ro cụ thể thay vì hạ global limits.
• Bật định danh mạnh hơn (yêu cầu API key, giảm phụ thuộc vào IP) để tránh chặn mạng chia sẻ.
• Capture mẫu: top key, top IP, user agents, và mẫu payload chính xác.

Trước khi tăng giới hạn cho khách hàng, kiểm tra pattern request bình thường, tỷ lệ endpoint, và xem họ có thể batch hoặc thêm backoff không. Đồng thời xác nhận họ không chia sẻ một key cho nhiều app.

Hàng tháng, review: endpoint bị giới hạn nhiều nhất, phần trăm traffic bị chạm limit, route tốn kém mới, và liệu quota còn phù hợp với usage thực.

Ví dụ thực tế: bảo vệ một public API mà không phá vỡ người dùng

Giả sử bạn vận hành một public API được hai app dùng: portal khách hàng (lưu lượng cao, ổn định) và công cụ admin nội bộ (lưu lượng thấp, nhưng thao tác mạnh). Cả hai dùng API key, và portal cũng có endpoint login cho người dùng cuối.

Một buổi chiều, một partner phát hành integration lỗi. Nó bắt đầu retry request thất bại trong một vòng lặp chặt, gửi 200 request/giây từ một API key. Nếu không có biện pháp, key đó có thể lấn át mọi người khác.

Giới hạn theo key thu hẹp vùng ảnh hưởng. Key lỗi chạm per-minute cap, nhận 429, và phần còn lại khách hàng vẫn hoạt động. Bạn cũng có thể có giới hạn thấp hơn riêng cho endpoint tốn kém (như export) để ngay cả "traffic được phép" không quá tải database.

Cùng lúc, một cuộc tấn công brute-force login bắt đầu bắn vào endpoint auth. Thay vì chặn toàn bộ dải IP (có thể ảnh hưởng người thật sau NAT), bạn làm chậm rồi khóa dựa trên hành vi: quá nhiều login thất bại theo account cộng với theo IP trong cửa sổ ngắn. Kẻ tấn công nhận các khoảng chờ ngày càng dài, rồi tạm khóa.

Một khách hàng thật vô tình nhập sai mật khẩu vài lần vẫn có thể phục hồi vì phản hồi của bạn rõ và nhất quán:

• 429 kèm Retry-After để client biết khi thử lại
• Khóa ngắn (ví dụ 10–15 phút), không cấm vĩnh viễn
• Thông báo lỗi nhất quán không tiết lộ liệu account tồn tại hay không

Để xác nhận sửa, bạn theo dõi vài metric:

• 429 rate theo API key và endpoint
• Tỷ lệ thất bại auth và số lần lockout
• P95 latency và CPU database trong sự cố
• Số key duy nhất bị ảnh hưởng (nên là ít)

Đó là hình ảnh của rate limiting bảo vệ backend mà không trừng phạt người dùng bình thường.

Bước tiếp theo: đặt chính sách nhỏ rồi lặp

Bạn không cần mô hình hoàn hảo ngày đầu. Bắt đầu với chính sách nhỏ, rõ ràng và cải thiện khi bạn hiểu hành vi người dùng thực.

Phiên bản đầu vững chắc thường có ba phần:

• Baseline per-key (requests per minute) bao phủ hầu hết endpoint
• Cap chặt hơn cho các endpoint tốn kém (search, export, upload, báo cáo phức tạp)
• 429 rõ ràng với thông điệp ngắn hướng dẫn client phải làm gì tiếp theo

Thêm lockout chỉ nơi rủi ro cao và ý định dễ suy luận. Signup, login, reset mật khẩu và tạo token là ứng viên điển hình. Giữ lockout ngắn ban đầu (phút, không phải ngày), và ưu tiên friction tăng dần: làm chậm, rồi chặn tạm, rồi yêu cầu kiểm tra mạnh hơn.

Viết chính sách bằng ngôn ngữ đơn giản để support có thể giải thích mà không cần engineering. Bao gồm những gì bị giới hạn (per API key, per IP, per account), cửa sổ reset, và cách khách hàng phục hồi.

Nếu bạn triển khai khi xây backend mới, AppMaster có thể là lựa chọn thực tế: bạn tạo API, định nghĩa workflow (bao gồm counters và quyết định lockout) bằng giao diện trực quan, rồi triển khai lên cloud hoặc xuất mã nguồn khi cần kiểm soát hoàn toàn.