✅ Checkpoint: rate limiting, quota và chống bot

By Better Wise

Quiz

  1. Rate limiting khác quota ở điểm nào?
    • Rate limiting giới hạn tốc độ theo cửa sổ ngắn (ví dụ 60 request/phút), quota giới hạn tổng lượng theo chu kỳ dài (ví dụ 100 lượt/tháng).
    • Hai khái niệm giống nhau, chỉ khác tên gọi.
    • Rate limiting chỉ dùng cho khách chưa đăng nhập, quota chỉ dùng cho đối tác gọi bằng API key.
    • Rate limiting đếm bằng database, quota đếm bằng Redis.
  2. Endpoint POST /api/summarize của bạn cho khách vãng lai dùng thử và khách đã đăng nhập dùng nhiều hơn. Cách ghép rule nào đúng theo bài học?
    • Chỉ dùng IP cho tất cả, vì user ID có thể bị né bằng cách tạo nhiều account.
    • Chỉ dùng user ID cho tất cả, vì IP hay bị NAT và proxy.
    • IP ở lớp ngoài với hạn mức thấp cho khách vãng lai, user ID ở lớp trong với hạn mức cao hơn cho người đã đăng nhập.
    • Dùng session ID của từng tab làm khóa để đếm chính xác hơn.
  3. Vì sao không nên đếm quota bằng cách đọc GET rồi ghi SET used + 1?
    • Vì GET và SET tốn nhiều bộ nhớ hơn INCR nên Redis sẽ đầy.
    • Vì lệnh SET không hỗ trợ giá trị số nguyên.
    • Vì SET tự động xóa TTL của key nên không cần EXPIRE.
    • Vì đó là race condition: nhiều request song song cùng đọc một giá trị cũ và cùng ghi đè, khiến user vượt quota.
  4. Thứ tự kiểm tra nào tiết kiệm tài nguyên nhất cho một request gọi API AI?
    • Gọi API AI trước để kiểm tra model còn hoạt động, sau đó mới validate input.
    • Parse JSON đầy đủ trước, sau đó mới kiểm tra Content-Length.
    • Query database đếm quota trước, rồi parse JSON, rồi kiểm tra kích thước payload.
    • Content-Length, auth, rate limit, schema, quota, rồi mới gọi API AI.
  5. Đồng nghiệp viết if (req.body.captchaOk) { cho qua }. Vì sao phải sửa?
    • Vì captchaOk là tên field không hợp lệ trong JSON.
    • Vì client tự khai thì bot chỉ cần gửi captchaOk: true; token phải được verify ở server bằng API của provider.
    • Vì captcha chỉ được verify ở client để giảm tải server.
    • Vì phải dùng visible captcha thay cho invisible captcha.
  6. Với endpoint gọi API AI bên thứ ba, khi captcha provider gặp sự cố (downtime) bạn nên chọn hướng nào?
    • Fail closed: từ chối request và trả lỗi rõ ràng, vì bot có thể quét sạch quota trong lúc provider chết.
    • Tắt luôn rate limiting và quota để bù lại việc thiếu captcha.
    • Fail open: cho qua tất cả để không làm gián đoạn người dùng thật.
    • Chuyển sang kiểm tra captchaOk do client gửi để thay thế provider.
  7. Khi client vượt giới hạn, API nên trả về mã HTTP ____ kèm header Retry-After để client biết khi nào được thử lại.
  8. Để tăng bộ đếm quota an toàn khi có nhiều request song song, bạn dùng lệnh Redis ____ (atomic), kèm EXPIRE khi tạo key lần đầu.
  9. Một field ẩn trong form mà người thật không thấy nên không điền, còn bot thì điền, được gọi là ____.
  10. Hãy tự đánh giá khả năng của bạn khi dựng chuỗi bảo vệ cho project: rate limiting theo IP và user, quota theo user, validate input sớm, và captcha chống bot.

Sign in to submit answers.