We're still seeing some concurrent load issues when lots of users come onto the site concurrently, and it happens in waves when the tokens are re-validated.
[ ] make sure to single flight has verified_email across all calls to odysee-apis. I.e. when a user loads odysee, 10 calls might be made that require verified email - only 1 should hit internal apis, the rest would wait for that response, and the process the other 9 calls with the cached data.
We're still seeing some concurrent load issues when lots of users come onto the site concurrently, and it happens in waves when the tokens are re-validated.
[ ] make sure to single flight has verified_email across all calls to odysee-apis. I.e. when a user loads odysee, 10 calls might be made that require verified email - only 1 should hit internal apis, the rest would wait for that response, and the process the other 9 calls with the cached data.
[x] spread out the waves. This can be done by adding a different validity period for different users, which helps spread the 2nd wave/third/etc waves. Similarly done in livestreamer: https://github.com/OdyseeTeam/livestreamer/blob/a9c54cb63c324ab4b2dd965c9325d38a334869f3/odysee/sdk/sdk.go#L73