Il est effectivement judicieux d'associer Redis et MongoDB :ce sont de bons coéquipiers. Vous trouverez plus d'informations ici :
MongoDB avec redis
Un point critique est le niveau de résilience dont vous avez besoin. Redis et MongoDB peuvent être configurés pour atteindre un niveau de résilience acceptable, et ces considérations doivent être discutées au moment de la conception. De plus, cela peut limiter les options de déploiement :si vous souhaitez une réplication maître/esclave pour Redis et MongoDB, vous avez besoin d'au moins 4 boîtes (Redis et MongoDB ne doivent pas être déployés sur la même machine).
Maintenant, il peut être un peu plus simple de garder Redis pour la mise en file d'attente, pub/sub, etc... et de stocker les données utilisateur dans MongoDB uniquement. La logique est que vous n'avez pas à concevoir des chemins d'accès aux données similaires (la partie difficile de ce travail) pour deux magasins présentant des paradigmes différents. De plus, MongoDB a une évolutivité horizontale intégrée (ensembles de répliques, auto-sharding, etc ...) tandis que Redis n'a qu'une évolutivité à faire soi-même.
Concernant la deuxième question, écrire aux deux magasins serait le moyen le plus simple de le faire. Il n'y a pas de fonctionnalité intégrée pour répliquer l'activité Redis sur MongoDB. Concevoir un démon écoutant une file d'attente Redis (où l'activité serait publiée) et écrivant sur MongoDB n'est cependant pas si difficile.
