feat: deviate Redis expiration time

[PooyaRaki]

Summary

This PR introduces a random deviation to Redis key expiration times to prevent cache stampedes and reduce the likelihood of simultaneous expirations. By spreading out key expirations, we help distribute network load more evenly and avoid putting unnecessary pressure on other services like the TX service.

Changes

• Added logic to apply a random deviation to Redis TTL values.
• Ensured the deviation stays within a safe and configurable range.

[schmanu]

Why do we do this?
Do we have any evidence that redis cannot handle it when multiple keys expire at the same time?

The way redis expires keys this does not really make sense IMO:

A key is passively expired when a client tries to access it and the key is timed out.

So there is no internal redis tasks that tries to run at the same time for all expired keys.

[gjeanmart]

I left a few minor comments, overall, this looks good 💪

Similar to Manu's question: do we have clear evidence of Redis stampedes occurring in prod? Also, I’m curious if this could be mitigated directly at the Redis config level?

[PooyaRaki]

@schmanu @gjeanmart This happens because when all keys expire at the same time, it puts pressure on CGW. Since the service aggregates multiple endpoints—including expensive ones like transactions—this leads to additional load on the TX service as well. To reduce this pressure, I’d like to distribute the traffic by randomizing the key expiration times. I’ll update the PR description accordingly.