[Feature]: Bandwidth-based (response-size) rate limiting support in WSO2 API Platform Gateway

Please select the area the issue is related to

Gateway

Please select the aspect the issue is related to

Aspect/API (API backends, definitions, contracts, interfaces, OpenAPI)

Suggested Feature

This issue has been created to track the effort related to the feature Bandwidth-based (response-size) rate limiting support in WSO2 API Platform Gateway.

Requirment

API Manager's throttling operates on request count, and the existing "bandwidth" throttling policy measures the size of the incoming request only not the size of the response returned by the backend.

This is a gap for APIs where the meaningful load is the volume of data returned, not the number of requests. A common example is an image- or file-serving API (e.g. one following the IIIF image protocol) where response sizes vary enormously on the same API and operation:

Some calls return many small payloads e.g. image tiles of a few KB each (typical of interactive zoom/pan in a viewer).
Other calls to the same operation return a single large payload e.g. a full-resolution image of several MB.

Because these requests are simple GETs with little or no request body, request-body bandwidth throttling sees effectively nothing in either case, and request-count throttling cannot distinguish them: a limit high enough to allow legitimate high-frequency small-payload access also permits repeated large-payload downloads, while a limit low enough to constrain large downloads breaks normal small-payload usage.

Related Issues

No response

Steps to Verify

• Design Document — A detailed design document has been created and reviewed, covering architecture, data flow, and edge cases.
• Design Mail — A design summary email has been sent to relevant stakeholders for awareness and feedback.
• Code Review — All code changes have been peer-reviewed and approved according to the project's review standards.
• Testing Complete — Adequate unit, integration, and/or end-to-end tests have been written and are passing.
• Documentation Review — User-facing and/or developer documentation has been updated to reflect the new feature and reviewed.
• Feature Complete — The feature is fully implemented, all checklist items above are done, and it is ready for release.

Start with the Gateway's existing request-count and bandwidth throttling behavior, focusing on how backend responses are observed and measured. Define the architecture, data flow, and edge cases for response-size limits, then review the design with stakeholders before implementation. Done includes approved design, code review, tests, documentation, and a completed feature checklist.