Skip to content

20230525-Do-not-use-Redis

Background

We have quite recently started using Redis (Azure Redis Cache) in a couple of places, for two reasons, cache of data, and distributed locks. However, it does not seem we have any real reason to use it hence this suggestion to stop using it.

Decision

We should avoid using Redis until we have a very compelling use case

Reasoning

Several different checked where made:

  • Comparison of lock performance between Redis and SQL Server (using the same underlying .NET Shared Lock library). Both SQL Server locks and Redis locks perform very well, and SQL locks are on the same order of performance as Redis.
  • Look at performance of SQL DB calls compared to Redis Cache lookups as seen from our code. Both options has a baseline duration of <=1ms. At the same time, for the uses we have we do not benefit from offloading the DB, the relevant queries would consume 0 DTUs.

For additional details, see https://docs.google.com/presentation/d/1NX1svKVBn3SacO18Nu4dTWiTj9Ugq31QKUuW9Z4Z3Gs/edit?usp=sharing

Consequences

  • We need to remove existing Redis Cache usages, and replace with normal DB lookups. Mainly two usages, Locations and SalesTool?
  • Make a replacement for Lock implementation in platform based on SQL Server instead of Redis. Should be easy since the underlying 3rd party library already supports this.
  • Update areas to use the updated Lock implementation, and remove the old (including any terraform infra)
  • It will not be as easy to share locks between Areas (i.e. User and Terms), but shared locks between areas should be avoided anyway.

Notes (optional)

The importance of migrating the existing usages of Redis over to SQL is not that high, Redis is not too expensive and not very maintenance heavy. However, we should make sure to do it sooner or later.