[deviceauth-enterprise] cache info about auth set status
Description
In the deviceauth service we optimized (using cache) the path where accepted device is asking for the JWT token.
Unfortunately, it looks like pending and rejected devices may generate big load on the DB when sending auth requests.
We could optimize this path using cache too - we could cache the status of the auth request (using id data hash, key hash, auth set id and the device id in the caching key).
When the device will send the auth request we can check the cache first.
Auth sets cache should be invalidated when the status of the auth set is being changed, when the auth set is being removed and when the device is being removed (as part of this task it should be verified when the cache should be invalidated).
In the deviceauth service we optimized (using cache) the path where accepted device is asking for the JWT token.
Unfortunately, it looks like pending and rejected devices may generate big load on the DB when sending auth requests.
We could optimize this path using cache too - we could cache the status of the auth request (using id data hash, key hash, auth set id and the device id in the caching key).
When the device will send the auth request we can check the cache first.
Auth sets cache should be invalidated when the status of the auth set is being changed, when the auth set is being removed and when the device is being removed (as part of this task it should be verified when the cache should be invalidated).
Acceptance criteria:
use redis for caching auth set status;