ramsestom
commented
8 years ago Another option would be to simply implement it as a private feathers service (not exposed to real users) using websocket connections (with socket.io or primus) where each node would be a 'client' of the others that would be listening for some synchronization message (a messages containing the event that need to be propagated). The only drawback I see is that it would increase the number of connections on each node (if you have 50 nodes, each node will have 98 new connections (1 to each other node he is listening sync events from and 1 to each node he is sending sync events to) instead of a unique connection to the MongoDB or redis instance (But that could probably be reduced with some more clever disperse mesh where each node only connect to a limited number of neighbors and can relay sync events. Not an easy task to code though).
Or you could simply have a feathers server dedicated to this synchronization that would run on one of the nodes of your cluster (a 'master' node) and to which all other nodes (including himself he if also run one of your feathers app) would subscribe. Then, with a message service running on this server, you can just dispatch sync events to each node (you just have to listen to a 'created' event on each node and to 'create' a sync message containing the event each time you have to dispatch an event). This solution would be less faut tolerant though as if your 'master' node lost connection or crash, no sync would be possible between the remaining nodes (but it is currently the case already if your mongoDB or redis server crash).
daffl
I'm not even sure if this is possible but creating a mesh network of peer-to-peer nodes using WebRTC or something similar would be amazeballs. This would make things very fault tolerant and remove the need to run another service for the synchronization.
Less moving parts equals more better!!