# Rate limiting and queuing key assigns

System Requirements:-

#1 rate limit key assign to prevent overload DKG node

#2 improve UX -> not return error to users immediately but to retry as best as possible

#3 Put least code on dkg service, coz it is difficult to update dkg nodes in prod, whereas it is relatively easy to update sss service.

Request flow:-

- Step 1 - Key assign request is sent to all nodes's sss service within a region

- Step 2 - SSS service of each node will determine which node should initiate the key assign based on queue waiting algo.

- Step 3 - After determining the node, the determined node (sss service) will initiate the key assign.

- Step 3.a - Other nodes (sss service) waits for a backoff time. After backoff time each node checks if key assingment is done if not then position of other node is determined.
- Step 3.b - While keygen request is being processed other nodes sss services are also polling db to know the status of key assign. As soon as they get the key assign record in db they will return success response.

## Adding rate limits:-

- We can add rate limit just before step 3 lets call it step 2.a.

### Happy Case:-
- We will check rate limit of determined dkg service group using redis rate limiter and if rate limits are within bounds then we will send the keygen request.

- After receiving the response from dkg service node will send the http response and other nodes will be informed about key assign state via db polling as stated in step 3.b.

### Worst case:-

- If rate limits are reached and dkg service is in full load then we can do following:-

- Either we can throw error and let the frontend do retries. But this doesn't guarantees successfull key assign under high loads even after retries.

- We can use a queue to queue key assign requests for each dkg service group.

### Queuing Requests:-
- Each sss service will send the request to a common queue (queue will be shared by all sss service instances within a node)

- Queue will broadcast requests to sss service receiver at x req/sec.

- Each sss will be receive these request and each service will be `process (defined in next section)` only those requests which are added by it and ignore rest of the requests.

- If request is processed within http timeout we will return the response otherwise we can return a socket id which can be monitored by frontend.

- Issue with sockets approach:- Frontend has to monitor x number of sockets where x is number of nodes.

### After receiving request from queue sss service will do following:-

- It will check if the key is already assigned.

- If key is already assigned then it will send the response to frontend via socket if http timeouts.

- It will send the keygen request to dkg service group and wait for response

- It will send the response to socket if http timeouts.