Redis cache cluster

1

Redis makes a really nice global cache service. Replicas can be configured to allow writes with replica-read-only false. With a reasonably small dataset, replicas can be added and removed quickly too.

Making this work on Fly (currently) requires two applications.

  1. A “primary” Redis app with a min-count and max count of 1, it should not scale.
  2. A replica Redis app configured to replicate from the primary Redis, replica-read-only false, and no disk persistence.

The primary Redis is useful for propagating commands to all the replicas. A del sent to the primary will remove keys in all the replicas. A set will propagate to all the replicas. Writes to each replica are invisible to other replicas, so the best pattern for using this is to do most caching operations against the replica app, and only write to the primary app for things that need to be the same everywhere.

(Moved from here: https://github.com/superfly/fly/issues/294)

2

What’s the problem / limitation with the current Fly Redis? The need to switch databases to get the global behaviour? Or the free SQS broadcast being unsustainable (is it implemented with SQS? Thought I saw that somewhere.)

I really liked the built in Redis system, think it’s awesome. Would prefer to just use that - it already does what this is promising but better. If the broadcast is a problem might be easier to solve it with NATS.

3

This is actually how we’ll do the shared Redis as well. We love having a built in Redis for testing, the plan is to keep that and let people smoothly replace it with a setup like this when they need to.

It is currently implemented with SQS, yes. Some drivers don’t love it, it would make more sense to have a real Redis primary to write to.