Kiểm thử API rate limiting dưới burst: 429, Retry-After và fairness

Trước hết xác định đơn vị quota: request, token, byte hay cost; cửa sổ theo giây/phút; và key theo IP, API key, user, tenant hay route. Nếu thiếu định nghĩa này, cùng một kết quả 429 có thể được coi vừa đúng vừa sai.

Limiter cần bảo vệ backend mà không chặn nhầm client hợp lệ. Ngoài enforcement tại ngưỡng, phải kiểm tra burst allowance, thời điểm reset, header hướng dẫn client, fairness giữa tenant và hành vi khi kho quota phân tán chậm hoặc mất kết nối.

Đặt load generator ngoài gateway, quan sát gateway/limiter store và backend riêng. Tạo ít nhất ba nhóm client: steady hợp lệ, burst vượt quota và tenant nền để đo ảnh hưởng chéo. Gắn request ID, tenant ID và timestamp để nối log ba lớp.

Traffic profile nên gồm ramp, spike ngắn, sustained overload, synchronized retry và retry có exponential backoff+jitter. Tách idempotent/non-idempotent endpoint và request cost khác nhau; không để một GET nhẹ đại diện cho API ghi dữ liệu nặng.

Khóa thuật toán token bucket/sliding window/fixed window, bucket size, refill rate, clock source, scope và distributed consistency. Ghi rõ header được dùng: HTTP 429 là chuẩn trạng thái; Retry-After có thể là số giây hoặc ngày HTTP theo semantics của HTTP.

Kiểm soát keep-alive, HTTP/2 multiplexing, connection reuse, CDN/WAF/cache, client timeout và retry policy. Nếu generator tự retry mà không ghi nhận, offered load và accepted load bị trộn, làm sai kết luận.

Đo offered RPS, accepted RPS, rejected RPS, overshoot trong cửa sổ, false reject, response code mix, Retry-After accuracy, latency p50/p95/p99, backend CPU/queue và recovery time. Fairness nên đo theo accepted share hoặc Jain’s fairness index khi phù hợp.

• KPI: Enforcement error · Ý nghĩa: Lệch giữa quota và accepted request · Bằng chứng: Gateway log + client result
• KPI: Overshoot · Ý nghĩa: Request lọt quá ngưỡng trong burst · Bằng chứng: Timestamp theo cửa sổ
• KPI: False reject · Ý nghĩa: Client dưới quota vẫn bị chặn · Bằng chứng: Per-key counters
• KPI: Retry amplification · Ý nghĩa: Retry làm tải tăng thêm · Bằng chứng: Attempt chain theo request ID
• KPI: Backend protection · Ý nghĩa: Service giữ SLO dưới overload · Bằng chứng: Queue/CPU/error/latency
• KPI: Fairness · Ý nghĩa: Tenant nền có bị starvation · Bằng chứng: Accepted rate từng tenant

• Kịch bản: Dưới quota · Tải: 70–90% steady · Câu hỏi pass/fail: Không false reject, SLO ổn định
• Kịch bản: Chạm quota · Tải: Ramp qua ngưỡng · Câu hỏi pass/fail: Enforcement đúng cửa sổ
• Kịch bản: Burst allowance · Tải: Spike ngắn · Câu hỏi pass/fail: Overshoot trong thiết kế
• Kịch bản: Multi-tenant · Tải: Một tenant xấu · Câu hỏi pass/fail: Tenant khỏe không starvation
• Kịch bản: Retry storm · Tải: Nhiều client đồng bộ · Câu hỏi pass/fail: Retry-After/jitter giảm khuếch đại
• Kịch bản: Store lỗi/chậm · Tải: Fault injection · Câu hỏi pass/fail: Fail-open/closed đúng chính sách
• Kịch bản: Clock skew · Tải: Node lệch có kiểm soát · Câu hỏi pass/fail: Không reset quota bất thường

Baseline backend không limiter để xác định công suất và tránh limiter che bottleneck khác. Bật limiter với một client, xác minh quota và headers. Sau đó mở rộng multi-key/multi-node, tăng burst theo bước, giữ nguyên request mix và ghi raw timestamps.

Pha resiliency làm chậm hoặc cô lập state store theo phương án được phép; xác nhận hệ thống fail-open hay fail-closed đúng tài liệu. Pha recovery giảm tải và đo thời gian accepted rate, latency, queue trở về baseline; kiểm tra bucket không refill hoặc reset sai.

• Chốt quota unit, key, window và burst allowance.
• Tách initial request khỏi retry attempt.
• Kiểm tra 429 và Retry-After ở client thực.
• Báo accepted/rejected theo từng tenant.
• Quan sát backend queue, error và tail latency.
• Kiểm tra limiter store lỗi và clock skew.
• Lưu cấu hình, version, raw log và correlation ID.

Kết quả phụ thuộc thuật toán, topology phân tán, cache, client retry và request cost. Không suy rộng từ một endpoint sang toàn API. HTTP chỉ định semantics; quota cụ thể và pass/fail là chính sách dịch vụ, không phải con số do RFC áp đặt.

• HTTP 429: Trạng thái Too Many Requests.
• Retry-After: Gợi ý thời điểm client có thể thử lại.
• Token bucket: Cơ chế tích lũy token cho phép burst hữu hạn.
• Overshoot: Request được nhận vượt giới hạn thiết kế.
• Fairness: Mức phân bổ công bằng giữa client/tenant.
• Retry amplification: Retry làm tải tổng lớn hơn tải ban đầu.