Right now Envoy health checks are binary yes/no that determine whether a host should receive traffic. A possible extension to this would be to provide additional information in the http health check response that allows the downstream to reprioritize the host.
For instance, you can imagine an upstream responding with x-envoy-health-degraded when the host is able to serve most traffic but say a Redis shard is down. This would make the downstream prefer other hosts that aren't declaring themselves degraded, presumably because they have a healthy Redis shard.
Floating this idea since it's something we have in our legacy RPC system and internal users seem to like it.
Right now Envoy health checks are binary yes/no that determine whether a host should receive traffic. A possible extension to this would be to provide additional information in the http health check response that allows the downstream to reprioritize the host.
For instance, you can imagine an upstream responding with
x-envoy-health-degradedwhen the host is able to serve most traffic but say a Redis shard is down. This would make the downstream prefer other hosts that aren't declaring themselves degraded, presumably because they have a healthy Redis shard.Floating this idea since it's something we have in our legacy RPC system and internal users seem to like it.