Cache responses across service

[Flarp]

As of right now, all requests go directly from an NGINX reverse proxy to the main Rocket application, which then interfaces with a Postgres backend. This service is likely to be read-heavy rather than write-heavy, so some additional infrastructure could possibly greatly decrease response time.

• Explore a Varnish cache that, for unregistered users, sends a cached version of a graph/search result rather than hitting the Rocket/Rust backend. The Rust backend will need to have an HTTP client (like reqwest) that sends PURGE requests to the cache when a graph is edited, to ensure up to date information.
  • The efficiency of this cache will depend on the proportion of active users who are registered with the service: registered users have progress information associated with graphs, so caching this information in Varnish is likely not useful as it changes as often as it is read. A Redis cache (described below) decouples these pieces of information.
• Provision a Redis cache that caches
  • Knowledge graphs
  • User progress for graphs
  • Notifications (limited amount)
• These pieces of information will have dynamically generated keys and will be serialized with bitcode into strings in the database.
• Implement a cache manager as a request guard (implementing FromRequest in Rocket) that attempts to secure connections to both the Postgres and Redis databases (optionally, allowing for non-functional caches), and abstracting over operations on these two databases to encapsulate functionality. This managed cache will be passed to routes, rather than Connection<Db> as it currently is.
  • If a Varnish cache is implemented, this cache manager should make appropriate HTTP PURGE requests to the Varnish server when an update operation is performed.

[Flarp]

With the inclusion of a Redis cache, it makes little sense to use a Varnish cache as this information will already be available in memory. The Redis cache will be used instead for both registered and unregistered users, to avoid needing to maintain multiple infrastructures with the same purpose.

Moreover, the Redis cache should also cache the current trending graphs of the day, week, month, and all time, as these computations are expensive (requires querying the entire likes database for day-week-month, but the like_count column in the knowledge graph table can be used for all time, which can save some computation time). It should be cleared about every 15 minutes (using some kind of Redis TTL) in order to be relatively up to date.