Proposal to add redis caching

[WcaleNieWolny]

Currently the update url does not use any caching. I propose we add redis to reduce the load on the postgress db My proposal is to do the following:

• Create a new cached_updates url
• Secure the current updates url, (require API_KEY making it internal)
• When users hits the cached_updates get app_id, device_id, version_name from the request
• Create a lua redis script that takes the values from above

• This script should have the following logic: (pseudo code)

  const app_key = getKey(`app_${APP_ID}`;
  // app_key can be either "defined", "non-existent" or "undefined"
  if (app_key === "undefined") {
   // It might not exist in the cache
   return 'app-undefined'
  } else if (app_key === "non-existent") {
   // It was checked in postgress, this app does not exist
   return `app-does-not-exist`
  }
  
  const device_version_key = getKey(`${DEVICE_ID}_${VERSION_NAME}`)
  // device_version_key can be either "general", "overwritten", "undefined"
  if (device_version_key === "undefined") {
   // We have a new device in an existent app, send req to old endpoint and create new key
   return 'device_overwritten'
  } else if (device_version_key === "overwritten") {
   // Do not cache
   return 'device_overwritten'
  }
  
  // this is the raw response, we have cached the response
  return getKey(`ver_${VERSION_NAME}`)

  This new endpoint would handle communication between redis and the old endpoint. A simple PoC can be seen here

  We would also create new endpoint for invalidating cache (for example when new version is uploaded or device is overwritten)

  As for the costs, it is hard to say how much we would save. I included a price calculation for redis with my current data but I am not sure how much load we can remove from supabase and how much supabase currently costs.

Given that we have 7M request per day (data from martin, not sure how accurate) and would probably fit in some of these fixed plans (redis enterprise)

I strongly believe that with a strong caching we can reduce the load on supabase by at least 50-80% making the extra cost worth it

[WcaleNieWolny]

Further price calculation would require data from @riderx (Number of apps, price for supabase, number of devices that are overwritten in any way, number of devices, perhaps even active uses of all apps, request to the updates endpoint per day)

Also AB testing / progressive deploy is an interesting issue. This is not easy to implement however it would allow capgo to scale more efficiently

[WcaleNieWolny]

I have implemented further PoC for this. I have modeled the redis data in the following way:

This allows for a very efficient caching of data. When someone uploads a new version we invalidate (remove) all of the ver_* keys from this hash (hash is just an object in redis AFAIK)

When someone overwrites a device we remove said device from the cache thus allowing the cache keys to stay between version uploads. The way I see this is that we can have the ver_* keys with an infinite TTL and the device_* keys with a TTL of 3 days (for example 3 days)

[WcaleNieWolny]

Further information on this:

I will not be using lua. Lua is pointless, sure it might reduce the overall reads but it adds complexity and a potential bottleneck. In the PoC I managed to avoid lua.

Another thing is that I think that in the final impl the old endpoint will get removed and replaced with an internal JS call (Thus avoiding the entire network stack allowing for faster caching)

Redis also add a lot of options for improving the stats endpoint as it adds the pub/sub (allowing for batch SQL updates) or potentially moving stats from supabase to redis

[WcaleNieWolny]

I am strongly in favor of using zod for the new edge functions to avoid manual parsing.

Please let me know if the usage of zod is acceptable

[riderx]

For provider, I was more thinking of this: https://upstash.com/docs/redis/overall/pricing it's more made for serverless. What do you think ? For zod, i'm not sure why you need it, can you elaborate more ?

[WcaleNieWolny]

I used zod as it allowed for quick and easy prototyping. It reduced the complexity of the code and decreased the potential for undefined errors.

I believe zod is not necessary for this, however migrating the manual parsing in all of the edge fns to zod might increase the overall error quality in our product