[GH-ISSUE #14] Idea: hashring replication #8

New issue

Closed

opened 2026-05-23 08:38:10 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-23 08:38:10 -06:00

Owner

Originally created by @rcoder on GitHub (May 11, 2022).
Original GitHub issue: https://github.com/appy-one/acebase-server/issues/14

So this is kind of a wild experiment, but I decided to spend a minute building a proof of concept to replicate data across acebase servers using a hash ring (ala memcached) instead of a single global IPC server:

https://github.com/rcoder/acebase-ring

The bulk of the actual replication logic is here: https://github.com/rcoder/acebase-ring/blob/main/src/server.ts#L80-L195

I'm almost certainly doing something wrong, and the code is just a big mess, but it's an interesting thought experiment at least. The advantage over a single IPC coordinator is of course the lack of a single coordinator that is persistently connected to all of the storage servers. (I.e., it's a true p2p cluster model.)

If I really find myself with time to burn I might try connecting replicas via WebRTC, but that's a science project for another day. :)

Originally created by @rcoder on GitHub (May 11, 2022). Original GitHub issue: https://github.com/appy-one/acebase-server/issues/14 So this is kind of a wild experiment, but I decided to spend a minute building a proof of concept to replicate data across acebase servers using a hash ring (ala memcached) instead of a single global IPC server: https://github.com/rcoder/acebase-ring The bulk of the actual replication logic is here: https://github.com/rcoder/acebase-ring/blob/main/src/server.ts#L80-L195 I'm almost certainly doing something wrong, and the code is just a big mess, but it's an interesting thought experiment at least. The advantage over a single IPC coordinator is of course the _lack_ of a single coordinator that is persistently connected to all of the storage servers. (I.e., it's a true p2p cluster model.) If I _really_ find myself with time to burn I might try connecting replicas via WebRTC, but that's a science project for another day. :)

gitea-mirror closed this issue

2026-05-23 08:38:12 -06:00

gitea-mirror commented

2026-05-23 08:38:14 -06:00

Author

Owner

@rcoder commented on GitHub (May 11, 2022):

Speaking of "doing something wrong", I think the above example may be accidentally exponential (b/c write amplification, perhaps?) based on the amount of log spam I'm seeing. :)

@rcoder commented on GitHub (May 11, 2022): Speaking of "doing something wrong", I think the above example may be accidentally exponential (b/c write amplification, perhaps?) based on the amount of log spam I'm seeing. :)

gitea-mirror commented

2026-05-23 08:38:15 -06:00

Author

Owner

@rcoder commented on GitHub (May 12, 2022):

Also, just in case it wasn't clear: this really is just a, "hey, this works and it's neat!" issue, not "please support this in addition to your tested, stable clustering model." Feel free to close w/o further discussion, and I can let you know if I go further with my experiments. :)

@rcoder commented on GitHub (May 12, 2022): Also, just in case it wasn't clear: this really is just a, "hey, this works and it's neat!" issue, not "please support this in addition to your tested, stable clustering model." Feel free to close w/o further discussion, and I can let you know if I go further with my experiments. :)

gitea-mirror commented

2026-05-23 08:38:16 -06:00

Author

Owner

@appy-one commented on GitHub (May 13, 2022):

Sounds cool! So, how would you describe the workings of the ring? Is it multiple servers with their own local db that distribute changes to all other known peers?

@appy-one commented on GitHub (May 13, 2022): Sounds cool! So, how would you describe the workings of the ring? Is it multiple servers with their own local db that distribute changes to all other known peers?