As far as I know it is possible to propagate refresh event among microservices via Spring Cloud Bus when Spring Cloud Config Server configuration changes. This then triggers pull of the latest configuration from Spring Cloud Config Server by the microservices notified.
Does this approach scale well? I mean we can have 1000s of microservice instances and if some global configuration changes then at the same instant all these 1000s of microservices will try to get the config from the Config Server. Doesn't this potentially mean overload and crash?
A solution to this issue could be to enforce some rate-limiting policy regarding requests to the Spring Cloud Configuration Server.
Rate-limiting policies enforce that only a limited amount of requests are processed per unit of time, guarding your application against resource exhaustion. A more comprehensive explanation of this policy and its flavors is detailed here.
For this particular case, you could throttle the requests to the Spring Cloud Configuration Server, by adding a rate limiter filter. You can add filters to the Spring Cloud Configuration Server as to any other Spring application. This post provides an example of how a security filter was applied - you can do something similar with a rate limiter filter.
If your Spring Cloud Configuration Server is running behind some reverse proxy server such as Nginx or Apache, you can configure a rate-limiting policy on the reverse proxy.