Regarding the other types of nodes, pure consumers are useful as "standby" nodes. They are ready to be swapped in when another host fails, but don't participate

Regarding the other types of nodes, pure consumers are useful as "standby" nodes. They are ready to be swapped in when another host fails, but don't participate in voting until they are swapped in. Swapping them in still requires a quorum of the previous nodes, so they are only useful in small numbers to be swapped in when another node fails. Nodes that are catching up are just a special case of this pure consumer type that shouldn't be promoted to be a full voting member until they are fully caught up. I'll add another type of node that sometimes comes in handy in certain network topologies. I've typically heard this called a "witness" - it is a voting member but doesn't store any actual data (just metadata) so it can't be a leader. The typical use for this is if you have a data center cluster with only two DCs. In that scenario you can make the number of nodes in each DC unbalanced so if the minority DC goes down you still have a quorum. But you can't make it so that if either DC goes down you can still have a quorum. So you add a third DC over a WAN that acts as an arbitrator between the two. Because it's far away, you don't want it to store all the data - keeping it in sync would be expensive. You only need it to know enough metadata to vote correctly. This obviously changes the failure characteristics quite a bit vs having 3 DCs in the cluster like normal. Such as how many real nodes and witness nodes you can tolerate failing. Latency while one of your your main DCs are down is much higher than normal (because you now need acks from the witnesses) but you at least keep running.