gRPC provides a set of policies and service configurations through the service_config technique:

• https://github.com/grpc/grpc/blob/master/doc/service_config.md
• https://github.com/grpc/grpc-proto/blob/master/grpc/service_config/service_config.proto

​

This is a mechanism for service owners to publish a configuration that is made available to their clients. It includes things like the retry policy and many more.

​

There is a service and client config and the client config has either the automatically passed config from the server or provides custom overrides in the client api. Those types have to match to stay compatible.

​

The currently preferred way to receive service configs from a service is to encode those in DNS-TXT records where clients resolve those upon channel connection. The general structure unfolds as:

​

​

1. Service Config Resolver via DNS
       - Clients should opt-in via channel options
       - Upon initiating the channel operation, lookup service config in json format
           - Parse the json service config
               - Error-Handling, validation
           - Distribute/Apply config to policies

​

1. Default service config set via client/channel api (fallback)
       - If no service config is found via DNS, apply client fallback

​

1. If no default config is provided either, fallback to empty config (defaults?).

​

​

Which is mentioned here:

​

https://github.com/grpc/proposal/blob/master/A2-service-configs-in-dns.md#service-config-via-dns
https://github.com/grpc/proposal/blob/master/A21-service-config-error-handling.md