Cache database user reads about exposure-notifications-verification-server HOT 6 CLOSED

Thank you for filing this bug @sethvargo!

@sethvargo @mikehelmick to tackle this, I'd recommend perhaps a distributed cache like Redis/Memcached as our caching layer, given that the app will be scaled out and caching in RAM means a trip if a request gets load balanced differently.
The alleviation am thinking of is to have the distributed here as an optional passthrough cache, whereby the CRUD calls pass through the Redis cache, but if Redis isn't available or the data isn't available, it'll fallback to fetching from the database.

If that sounds good I can send a PR implementing this logic. Thank you!

from exposure-notifications-verification-server.

I see per

from exposure-notifications-verification-server.

Yeah, we already have a Redis instance in the mix, so that is a safe choice.

I think it's fine to move forward with that and have the caching disabled by default (dev instance)

from exposure-notifications-verification-server.

Yea, generic read-through cache. The reason I haven't been tackling this is because all the redis libraries for Go have various tradeoffs and I haven't had time to weigh them.

from exposure-notifications-verification-server.

Not a problem, I've got y'all :) I examined a bunch of the libraries and I have used redigo by Gary Burd, and even rolled out an instrumented version of it https://godoc.org/github.com/opencensus-integrations/redigo/redis. I'll send a PR for it.

SGTM, turned off by default works.

from exposure-notifications-verification-server.

This is done!

from exposure-notifications-verification-server.