As of now, we have connection-based load-balancing only, which is managed either by the OS or by the user, depending on --accept-mode. However, we need request-level / app-level load-balancing to properly simulate microservice-based architectures.
A starting point is the MULTI-FORWARD operation, which spread a request across multiple nodes, and optionally waits for a subset of replies. For this new use-case, we'll an additional operation DISTRIBUTE - I believe that an additional tunable for the FORWARD operation is too much. Indeed, DISTRIBUTE works very similar to a (MULTI-)FORWARD, but picks only one node from within a list of candidates, based on a criterium.
In this scenario, the forwarding node :7891 has to query for statistics both nodes :7892 and :7893, pick the candidate with the least amount of active connections, and then FORWARD the rest of the command chain
As of now, we have connection-based load-balancing only, which is managed either by the OS or by the user, depending on --accept-mode. However, we need request-level / app-level load-balancing to properly simulate microservice-based architectures.
A starting point is the MULTI-FORWARD operation, which spread a request across multiple nodes, and optionally waits for a subset of replies. For this new use-case, we'll an additional operation DISTRIBUTE - I believe that an additional tunable for the FORWARD operation is too much. Indeed, DISTRIBUTE works very similar to a (MULTI-)FORWARD, but picks only one node from within a list of candidates, based on a criterium.
Example:
In this scenario, the forwarding node :7891 has to query for statistics both nodes :7892 and :7893, pick the candidate with the least amount of active connections, and then FORWARD the rest of the command chain