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.

...

The NORMALIZED_URI column must be unique since having 2 different throttles throttling rules 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.

...

• By having UserThrottleFilter periodically read the table (via a DAO) and updating the Map. 
• Wrap the Map with a synchronized singleton. Allowing a worker to update it.

...

When an request comes in, the request URI will be normalized using normalizeMethodSignature() AccessRecordUtils of the Synapse-Warehouse-Records project (copy it over). once

Once normalized, the url is compared to the cached throttled calls throttle rules to see if it is being throttled. if  

• If it is not throttled, proceed to next filter.
• If it is throttled, attempt to get a lock from the semaphore. The key used for the semaphore will be the userID + normalizedThrottledCall.
  • If a lock can be successfully acquired, proceed to next filter.
  • If we can not get a lock, block the request and return a HTTP 429 error code. otherwise proceed with the other filters.

Services

These services make updating rules more convenient.

...