0

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?

Kamil Roman
  • 973
  • 5
  • 15
  • 30
  • the scenario you mentioned here it just simple rest call, your each service will give a get call to the Config to get the updated config, so 1000 request per second to return data in few Kbs - i don't think that will be overload and failure – Ashish Shetkar Dec 09 '20 at 05:45

1 Answers1

1

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.

sashimi
  • 1,224
  • 2
  • 15
  • 23