Config first bootstrap and discovery first bootstrap are two different approaches for using Spring Cloud Config client in Spring Cloud-powered microservices. Let’s discuss both of them:

Config First Bootstrap 

This is the default behavior for any spring BOOT APPLICATION where Spring Cloud Config client is on the classpath. When a config client starts up it binds to the Config Server using the bootstrap configuration property and initializes Spring Environment with remote property sources.

• Config-first approach 

The only configuration that each microservice (except config-server) needs to provide is the following: 

• File:-  /src/main/resources/bootstrap.yml 
• spring.cloud.config.uri: http://localhost:8888 
• In config-first approach, even the eureka-server can fetch its own configuration from config-server. Point worth noting down here is that config-server must be the first service to boot up in the entire ecosystem, because each service will fetch its configuration from config-server. 

Discovery First Bootstrap 

If you are using Spring Cloud Netflix and Eureka Service Discovery then you can have Config Server register with the Discovery Service and let all CLIENTS get access to config server via discovery service. 

• Discovery-first approach 

This is not the default configuration in Spring Cloud applications, so we need to manually enable it using the below property in bootstrap.yml 

The benefit of this approach is that now config-server can change its host/port without other microservices KNOWING about it since each microservice can get the configuration via eureka service now. The downside of this approach is that an EXTRA network round trip is required to locate the service registration at app startup.