tbh y’all need to chill this thread is kinda unhinged

It seems to me like you know what you’re doing and wrote a library that makes sense for your case, but when describing it in the readme you (understandably) tried to put it into very general terms. But because it’s very general everyone is just going to project their own experiences onto it instead.

In a similar situation I found that explicit examples help. The sidecar thing makes sense to me; consider adding it to the readme.

I’ve just reread my post, and it sounds a bit toxic. I want to make clear that given that this implementation is poor, it is a good start and the whole idea is not strange, but it is a classic problem which was solved several times by other authors from Elixir community and what you’re doing with Mesh is a good starting point to explore the problem space

My personal recommendation would be to

1. Learn more about distributed systems. I would love to provide some books and resources that I personally find useful, but unfortunately very few of them are in English
2. Take a look at existing implementations, learn about their tradeoffs. For example, Horde library solves the similar problem, but it uses eventually consistent delta-CRDT merkle tree structure to (eventually) maintain the same version of the information about which processes belong to what groups. Other good example is ProcessHub which is, afaik, still in active development phase.
3. Learn more about consistent hashing algorithms and their applicability. These algorithms are very interesting because there is an exotic mix of finite field algebra and some empirical observations of how distributed systems change their memberships
4. Dont be afraid to ask questions. You can tag me in any thread or use the personal messages. I also provide mentorship and consulting services. But you can also just create topics on the forum. Discussions about distributed systems are especially welcome here

I am looking forward to seeing the new version of Mesh which would use some interesting distributed algorithm. Happy coding

Good catch — you’re right about the terminology.

Mesh currently uses deterministic hash-based sharding, not classic consistent hashing with a ring. Shards are fixed and process are mapped to shards via phash2/2.

That said, this is a deliberate design choice aligned with our use case. Mesh routes messages to virtual processes, not persistent data partitions. Actors are ephemeral, lazily created, and can be safely recreated elsewhere. As a result, minimizing “resharding cost” is not a primary concern for us.

Nodes joining or leaving do not change shard assignment — only shard ownership. There is no data migration involved, and no state is coupled to shard placement.

Rendezvous hashing is a great tool and could be explored in the future, but for now the current approach gives us simpler reasoning, O(1) routing decisions, and predictable behavior, which fits well with Mesh and Spawn’s actor model.

Still, thanks for pointing this out — we should probably avoid calling it “consistent hashing” in the docs and be more precise about the terminology. We’re always open to evolving the routing strategy as new requirements emerge.