Tileserver L1 cache design (Varnish vs. Redis)

[davenquinn]

The tileserver is designed with a L1 (memory) and L2 (on-database) cache.

We should consider moving the tile cache to a separate database (#15) if there are performance implications to having it on the same database/cluster. But keeping it in the same place as the Macrostrat database may prove fine, so let's start there.

Of more immediate interest, there are two potential approaches to the "L1" cache. So far we have set up a mostly-transparent HTTP response cache (Varnish) in front of the tileserver, which caches a set quantity of the most recent requests. This has several characteristics:

• Independent of our application code
• Memory cache is specific to each pod
• Cache expiry can be done by route if desired
• This may not "play nicely" with current request-logging approaches (Request logging #36) without figuring out Varnish's logging system

A "memory key value store" like Redis would allow finer-grained control but be more tightly coupled to our application.

• Logging and cache expiry could use reuse patterns also used for PostgreSQL-served queries
• Cache could (probably) be shared between pods
• This would likely duplicate a lot of the logic of our "on-database" cache, which could be good (similar logic and API) or bad (only a benefit to the extent that there is a large difference in reading a cached tile from Redis vs. PostgreSQL)

[davenquinn]

We're going with a Varnish L1 cache, as a Redis key/value store will basically have the same structure (with less well-defined persistence behaviour) as the PostgreSQL cache. If we need more performance from the cache, we can consider a dedicated tile-cache database or cluster.