0

I am working on an REST service which primarily provides 2 APIs: PUT request and GET request. During a disaster recovery, the service will be in a state where it cannot accept new PUT requests, but can still be able to provide response for GET requests. I am looking to see how I can temporarily disable/fail incoming PUT API calls (by returning 500s or anything other than 200) at runtime, while the service is actively undergoing a disaster recovery. The service runs on a set of hosts behind a load-balancer, with auto-scaling enabled. The PUT API requests need to be disabled temporarily on all the hosts running the service.

I have com across this post on updating configurations at runtime: java update properties file run time, but it looked like this requires manually updating the properties file on each of the hosts, which might not be optimal if we have a large number of hosts running the service.

Wondering if there are other approaches to achieve this. Thanks in advance!

share75
  • 69
  • 1
  • 10

2 Answers2

1

Mostly, Load-Balancer placed behind firewall. If you have access to your firewall, you can set a task before starting disaster recovery for set a rule in your firewall and blocking any connection to your target service or method using firewall. After DR completed, set a task for drop the rule and allow connections.

Afshin
  • 1,405
  • 10
  • 18
1

This is a classic use case for Redis or any other message broker.

So, you could create a channel in a Redis service. If your API enters disaster recovery, something publishes a message. All instances of the API are subscribed to that channel and receive the message, and cache it somewhere. Add a middleware to your routes that checks that cached value on every request, and returns an error if the application is in disaster recovery. Then, when your application is no longer in disaster recovery, send a message to the Redis channel causing all the servers to clear the value from cache.

This kind of solution is fast, clean, easy, and reliable. Changing application configuration just isn't something you want to try to do at runtime. Configuration is meant to be stable. It isn't state.

Charles Desbiens
  • 879
  • 6
  • 14