The purpose of this feature is to allow administrators to selectively control which API calls are throttled, without having to rebuild and deploy a new version every time a throttle is changed.

...

CREATE TABLE 'THROTTLED_CALLS'(
	'THROTTLE_ID' int(20) PRIMARY KEY,              --id of the throttle rule
	'NORMALIZED_URI' varchar(256) NOT NULL,        --normalized api URL, numbers such as {id} replaced with #
	'MAX_LOCKS' int(20) NOT NULL,                   --maximum number of locks per time block
	'LOCK_TIMEOUT_SECONDS' int(20) NOT NULL,        --duration of each time block in seconds
	'THROTTLE_EXPIRATION' bigint(20) DEFAULT NULL,  --optional expiration of the rule in unix timestamp. maybe not necessary?
	UNIQUE ('NORMALIZED_CALL')
)

The NORMALIZED_URI column must be unique since having 2 different throttles for the same API call would not make sense(maybe consider making this primary key instead of id?).

Reducing Table Accesses

UserThrottleFilter will have a in-memory cached version of this table. It would periodically check the THROTTLED_CALLS table and update its cached version to reflect the information in the database.

...

When an request comes in, the request URI will be normalized using normalizeMethodSignature() AccessRecordUtils of the Synapse-Warehouse-Records project (copy it over). once normalized, the url is compared to the cached throttled calls to see if it is being throttled. if it is, attempt to get a lock from the semaphore. The key used for the semaphore will be the userID + normalizedThrottledCall.

...