|
|
|
|
|
by mitchellh
4440 days ago
|
|
Thanks for prefacing the constructive criticism with the compliment. :) I want to clarify: Of all the buzz words Consul has, one thing Consul ISN'T is decentralized. You must run at least one Consul server in a cluster. If you want a fully centralized approach, you can just run one server. No big deal. Of course, if that server goes down, reads/writes are unavailable. If you want high availability, you run multiple servers. They leader elect to determine who will handle the writes but that is about it. It is "decentralized" in that you can send read/writes to any server, but those servers actually just forward the requests onto the leader. |
|
Now that i've re-read your architecture page, let me see if I understand this: the basic point behind using Consul is to have multiple servers agree on the result of a request, and communicate that agreement to a single node to write it, and then return it to the client. So really it's a fault-tolerant messaging platform that includes features that take advantage of such a network; do I have that right?
Also, your docs say there are between three and five servers, but here you're saying you only need one?