Has keeping user documents in separate databases been considered, studied or ruled out? along with implementing some sort of “communication system” between users, perhaps storing the same document in more than one user database?
Hi @bamatic
Yes this has been considered. The way I think this would be implemented would be with every user database on the server syncing all docs to a central database, and then syncing relevant updates back down to the users database again.
The main downside of this approach is it requires a lot of complicated replication between server databases. This adds server load, disk usage, and complexity by having to maintain thousands of replications. There’s also an increased lag because a document has more replication steps to go through before getting to the other users database.
The main upside is the replication between the phone and the server would be very quick because the server has already done all the work to figure out what changes are needed.
This is a conversation worth revisiting, particularly as we start thinking about ever larger scale and options like cold storage.
1 Like
Thanks @gareth for this answer
I’ve been thinking in this option of having the users database’s and also the medic database acting as the central database even if this means to duplicate all docs
Other option that has came to my mind is a kind of publisher/subscriber architecture with a process reading for user’s _changes feed that would be publishing docs to appropriate topics using apache kafka or something like that and subscribers writing to the user’s databases as needed. The publisher process would need a fast way to know which users are “interested” in a particular contact
In all clouds we can find a publisher/subscriber managed service that could be used for this
At MUSO we will continue thinking in these things and we let the CHT community know if we find something interesting.
2 Likes