Kiểm thử API rate limiting phân tán: fairness, burst và Retry-After

Policy phải nêu quota key là API key, user, tenant, IP, route hay tổ hợp; đơn vị là request, byte, cost unit hay concurrency; cửa sổ và burst capacity; behavior khi state store lỗi; và endpoint nào được miễn trừ. Nếu các điểm này chưa rõ, kết quả 429 không thể được đánh giá đúng/sai.

RFC 6585 định nghĩa 429 Too Many Requests nhưng không bắt buộc server nhận diện user hoặc đếm request theo một cách duy nhất. RFC 9333 chuẩn hóa các RateLimit fields để truyền limit, remaining và reset, song policy thực tế vẫn do dịch vụ quyết định.

Topology đại diện gồm client generator ở nhiều source/region, load balancer, ít nhất hai gateway node, state store hoặc control plane quota, backend và telemetry collector. Thêm network emulator giữa gateway–state store để tạo latency/loss mà không làm sai tải client.

Traffic profile phải tách steady request, burst, long-lived request, request cost khác nhau và nhiều tenant. Giữ payload, response size, connection reuse, TLS, cache và backend time ổn định khi đo rate limiter.

Khóa gateway/version, policy revision, node count, algorithm, clock source, state consistency, load-balancing key và retry configuration. Warm-up cache/connection trước baseline. Đồng bộ timestamp generator, gateway, store và backend.

Quét request rate, burst width, tenant count, key cardinality, node churn, clock skew, state-store latency/loss, region failover, client retry và Retry-After. Với HTTP/2/HTTP/3, phân biệt request rate với connection count.

KPI gồm admitted/rejected rate, overshoot, undershoot, fairness per tenant, valid-request latency, 429 precision, Retry-After accuracy, counter convergence, backend protection và recovery time. Dùng percentile và cửa sổ ngắn; average dài có thể che burst vượt quota.

Bằng chứng gồm generator manifest, response headers, gateway decision log, state-store metric, backend accepted request và policy snapshot. Gắn request ID, tenant ID và node ID để chứng minh quyết định phân tán.

Ngưỡng cần lấy từ SLO và threat model. Một hệ thống có thể chọn fail-open cho API ít rủi ro và fail-close cho thao tác nhạy cảm; phải kiểm thử đúng từng route.

• Dưới quota — Kỳ vọng: Hầu hết request hợp lệ được nhận; KPI chính: false reject, latency; Fail nếu: 429 sai hoặc latency tăng quá ngưỡng
• Burst trong allowance — Kỳ vọng: Nhận đến burst capacity; KPI chính: overshoot/undershoot; Fail nếu: cắt sớm hoặc vượt quá mức cho phép
• Vượt quota kéo dài — Kỳ vọng: 429 theo policy; KPI chính: admitted rate, headers; Fail nếu: backend vẫn quá tải
• Hai tenant — Kỳ vọng: Quota độc lập/công bằng; KPI chính: Jain index hoặc ratio; Fail nếu: noisy neighbor chiếm quota khác
• Một gateway mất — Kỳ vọng: State không sai kéo dài; KPI chính: recovery, overshoot; Fail nếu: quota reset hoặc double-spend
• State store lỗi — Kỳ vọng: Fail mode đúng thiết kế; KPI chính: availability/risk; Fail nếu: behavior không xác định

Chạy single key dưới, đúng và trên quota; kiểm tra status, body và headers. Sau đó đổi key dimension, route, method và request cost. Xác minh limit/remaining/reset không âm, không nhảy ngược bất hợp lý và nhất quán với quyết định thực tế.

Thử boundary ngay trước/sau reset, clock skew và concurrent arrivals. Client phải tôn trọng Retry-After có jitter/backoff; kiểm tra idempotency để retry không tạo side effect lặp.

• Ghi policy bằng ngôn ngữ có thể tính được.
• Kiểm chứng single-node trước distributed.
• So admitted request với backend log.
• Đánh giá 429 và headers theo từng tenant.
• Kiểm tra boundary/reset và clock skew.
• Lưu request-level evidence.

Tăng tải theo bậc, sau đó burst đồng thời từ nhiều tenant. Theo dõi gateway CPU, state-store latency, counter conflict và backend saturation. Gây node restart, partition ngắn, replica failover và autoscaling để phát hiện quota reset/double-spend.

Mô phỏng client retry đúng và sai: retry ngay lập tức, exponential backoff, jitter và giới hạn attempt. Mục tiêu là chứng minh 429 không biến thành retry amplification làm tải lớn hơn ban đầu.

Bắt đầu shadow/count-only nếu hỗ trợ, sau đó canary theo tenant/route. Dashboard phải hiển thị offered, admitted, rejected, top quota key, backend saturation và client retry. Cảnh báo cả overshoot lẫn false reject.

Rollback gồm policy revision trước, cách vô hiệu hóa theo route và giới hạn bảo vệ backend thay thế. Mọi thay đổi algorithm, node count, region, identity mapping hoặc SDK retry phải kích hoạt regression.

Không suy throughput tối đa từ một policy nhỏ hoặc một loại request. Kết quả phụ thuộc algorithm, clock, consistency, key cardinality, connection protocol và backend. Header đúng cú pháp chưa chứng minh quota được thực thi đúng.

Lab cũng không mô phỏng hết NAT chia sẻ, bot phân tán hay client không tuân thủ. Báo cáo phải ghi rõ traffic profile, fault window và sai số timestamp.

• Quota key: định danh dùng để gom và đếm request.
• Burst allowance: dung lượng cho phép vượt tốc độ đều trong thời gian ngắn.
• 429: HTTP Too Many Requests.
• Retry-After: thời điểm/khoảng client nên chờ trước khi thử lại.
• RateLimit fields: header chuẩn hóa cung cấp limit/remaining/reset.
• Overshoot: request được nhận vượt policy.
• Noisy neighbor: tenant làm suy giảm tenant khác do tài nguyên chia sẻ.