In terms of scalability, Workflow Manager farm sits on top of a Service Bus farm, and can only either be a single server or three servers.
The most important factor is that there is no other supported topologies, also most importantly, Service Bus reaches a quorum with three or five nodes.
So, if you want to deploy a highly available Workflow Manager farm, you of course will need three or five machines in our farm.
Because, as previously referred Workflow Manager sits on top of Service Bus, so this means that you “get high availability for free” via its scale out model.
This means, that Service Bus takes care of business behind the scenes for us and the correct node will handle tasks. This is automatic and also provides the performance and throughput benefits of a farm deployment.
There is however one thing that you need to consider on this out-of-the-box load balancing given by the Service Bus, you need to understand that this mechanism of load balancing provided by the Service Bus is internal to the WFM Farm and not external.
For example, when we create a connection to a Workflow Manager farm from a SharePoint farm with the Register-SPWorkflowService cmdlet we pass in a WorkflowHostUri parameter.
This typically is the host name of a Workflow Manager host, If we have three/five Workflow Manager hosts, you might get confused about what host you should use.
In reality, you can use anyone of the hosts, this will always work.
The problem here might be if that particular host is down for whatever reason, in this case your Workflow will be broken and we cannot configure or execute any SharePoint 2013 workflows.
In this case, the solution is not complicated, you will need to implement the usual process of load balancing for the Workflow Manager Farm, in a way that the Sharepoint Farm that is consuming the Workflow Manager can communicate with its Virtual Name. This should be pretty forward (you can use Application Request Routing or any other approach of Network Load Balancing).
All of this are explained in detail in our article:
Scaling out Workflow Manager 1.0 – https://msdn.microsoft.com/library/azure/jj250902(v=azure.10).aspx
In there you can confirm this statements:
“You don’t need to change your workflows to take advantage of Workflow Manager 1.0 scale-out topology. You also don’t need to worry about how the execution of workflows s distributed between servers in the farm. All Workflow Manager 1.0 servers that joined the farm use efficient algorithms to process workflow instances with pending work.”
If you also want to implement scalability when connect to the WFM, you can use the bellow article that explained with great details all the steps to implement this
You just need to be careful when you create your Multi-Node Farm certificate, you must make sure that the certificate is a domain certificate.
A domain validated SSL is a digital certificate in which the validated identifying information of the certificate is limited to the domain name and works across any machine in the domain.
For example, the subject name of the certificate has a value of *.domain.
Hope that helps.