If you set up Postgres read replicas, make sure your queries are covered by appropriate indexes, and your hot queries are handled by Postgres from RAM anyway - do you really need a separate Redis cache?
I feel like anytime I'm going to pull in Redis for a cache, it's going to be for data that I'm not interested in having guaranteed persistency for, like session tokens, and so it'll be for data that I wouldn't be storing in Postgres anyway?
But you want to be able to store/have single source of authority and update them using a SQL database.
This would then eliminate the need to maintain a separate lambda or cron job or something like that to keep them in sync.
https://github.com/redfly-ai-org/redfly.ai/blob/main/LICENSE
The code in the repo just seems to be connection code ("provides a way for anybody to test our Redis synchronization service on demand") rather than the sync service itself
It isn't actually. The codein the repo just seems to be some scaffolding.
> public const string AesKey = ...
Also, the way AES is used in the code is not good practice. It seems to be using plain AES ( https://learn.microsoft.com/en-us/dotnet/api/system.security... ), which isn't meant to be used bare like that. It needs to be coupled with a digest algorithm to protect the ciphertext. Maybe use AesGcm instead?
Also, AES is deterministic and will encrypt the same data the same way every time. This means if you are encrypting a lot of fields you will be able to do statistical attacks. Using an initialization vector with AES GCM is similar to salting a hash. This way there is no statistical method to determine the contents of the ciphertext.
