[dpedu]

How would the architecture in the OP mesh with master-slave postgres setups? If I write a cache item how can I be certain the freshest entry is read back from the read-only slave? Can/do I pay a performance penalty on writes waiting for it to be synchronized? Is it better, when it comes to caching, to ignore the slave and send all read/write cache related queries to the master?

All of these questions go away or are greatly simplified with redis.

[watermelon0]

They don't really go away, because if you need read-only replicas with PostgreSQL, there is a good chance that you will also need read-only replicas with Redis.

Similarly to Postgres, Redis replication is also async, which means that replicas can be out-of-sync for a brief period of time.

[tetha]

I was unsure to comment this: You can mark postgres replicas as sync replicas. Writes on the leader only commit fully once the writes are fully replicated to all sync replicas. This way postgres could ensure consistency across several replicas.

This however can come with a lot of issues if you started to use this to ensure consistency across many replicas. Writes are only as fast as the slowest replica, and any hickup on any replica could stall all writes.

What I wasn't sure about - IMO in such a situation, you should rather fix the application to deal with (briefly) stale information, and then you can throw either async postgres replicas at it.. or redis replication, or something based on memcache.