Salut,

Je ne comprends pas trop. Si j’ai bien compris tu veux des sessions sticky vers une base de données sur deux, et puis tu veux avoir de la replication lazy (dont l’utilité ne m’est pas très claire, pourquoi l’utilisateur ne restera pas sur son serveur, un tout petit peu distant quand il est en « roaming »)? C’est pour de la haute-dispo? Pas sûr que c’est la bonne solution.

Donc en gros tu assigne à l’utilisateur la base que tu veux tu le mets dans la session ou même dans un cookie si tu veux, il reste toujours sur sa base et basta. Pas besoin de répliquer. Si jamais tu veux tu peux toujours faire une procédure de migration des comptes entre les deux serveurs. Quand il se loggue tu peux toujours vérifier sur quelle base il est censé aller. A la limité tu peux toujours répliquer cette info.

Une bonne manière de faire c’est peut-être d’utiliser simplement Postgres avec des schemas per utilisateur. Tu peux alors avoir sur chaque côté geographique deux instances. Un master et un slave. Tu peux même alors répliquer les schémas (en gros chaque noeud devient master pour ses propres utilisateurs et slaves des utilisateurs de l’autre).

Si tu le fais avec du Ruby il y’a des supers-dupers outils pour ça. Regarde surtout https://github.com/influitive/apartment ça fait ça automatiquement plus ou moins.
Mais aussi https://github.com/bpot/data_fabric

Autrement, si ta donnée est non-volatile, elle pèse déjà une vingtaine de Go alors Redis, hmm je suis loin d’être sûr. Pour ce qui est du master/master CouchDB a été construit pour. Ca fait maintenant quelques années que je l’utilise plus trop mais si tu ne veux pas écrire du code du tout…