1

  1. Suppose we have N identical windows services (developed in C#/.NET) running at same time on N application servers. 'Unfortunately', every service has its own in-memory states (say, "at 10:00 PM I need to execute a job").

  2. Through a frontend web UI user may change the state (say, change job start time from 10 to 12) of one of these services.

My question: what is the best practice to synchronize the states between these services after user changes states? (Preferably in .NET platform).

p.s. you may wonder why we bother run the same service on different servers. That's because managers think redundant prevents single point failure. But it also brings up above issue when the service instance holds its own in-memory states that can be changed by user through a UI.

Any suggestion here is appreciated!

Felix Wang
  • 11
  • 3

1 Answers1

0

Sounds like you're using the local service state as the primary configuration/settings/etc. for each service instance. Since you want them to stay synchronized, that means updating each operating instance.

I can think of a number of approaches of how to solve this, but based on the info you've provided I'd go with centralized configuration with update polling:

  • A central db for configuration/settings, such as job times.
  • All services, on initialization, read from the central db to get settings/config and apply them in-state to the service instance.
  • Admin UI simply saves data to the config/settings DB.
  • All services periodically query for updates from DB and apply accordingly.

This is a simple distributed structure that makes each service responsible for acquiring its settings in order to operate (pull model), and is easier to manage than notifications out to each service instance (push model). It has the added benefit of allowing you to add more servers and service instances later without having to change application code or modify any configuration info.

jro
  • 7,372
  • 2
  • 23
  • 36