Watch Notification Pattern

There is an external configuration server which contains configuration details of services. Now whenever there is a change in any configuration the services need to be actively listening for configuration changes, This creates an always on connection consuming resources where not necessarily required. Or a broker is required to continuously publish the changes to different services making the overall infrastructure heavy.

Problem : Notify services whenever configuration value changes

Solution: Watch notification pattern. A broker less approach to publish changes across services

Prelude to watch notification service :

Before we divulge into the watch notification pattern lets have a look at attempts already done to solve the problem of notifying services

1. Service Broadcast Pattern

Actors: 

1. A group of services

2. External config server

3. A broker

Concept :

All services are subscribed to a broker. The external configuration service publishes 

a change to broker, which in turn is received by all the services.

        Cons:

• Every service must connect to broker
• Broker forms single point of failure
• No way of notifying service.
• More number of services, overwhelms broker

Service Broadcast pattern illustrated

        2. Domain Broadcast Pattern

Actors:

1. A group of services which are not logically divided into groups of domain

2. External Config server

3. A broker for each domain of services, servicing a certain set of services

Concept:

Similar to Service Broadcast Pattern, but each broker is responsible for a set of   

                services, and no broker to publish to all services. Increases performance.

Cons:

• Single point of failure within a domain
• Still broker based connection.

Domain Broadcast pattern illustrated

Actors:

1.External Configuration Server

2. A queue internal to config server or a rest endpoint

3. Services

4. An embedded message queue at the service or rest endpoint

Concept:

• At service start up, the service tries to get configuration details. While doing so the service registers itself with the config server.
•  Registering itself means, it gives a way for the external config server to     communicate back to the service itself.
•  In this way the config server keeps an internal list of all services registered to it.
•  Whenever the value in config server changes, it iterates through the list, connects with each internal queue of service and publishes the message. (Or sends a REST based request based on implementation)
•  If any service goes down, then the publish to internal queue of that service from Config server fails. When this fails the config server de-registers the service (removes the entry from its list)

Watch Notification Pattern Illustrated

                Cons:

• If the config server itself crashes, then no registration of services can take place till the config server is not up.
• Config server needs to persist the configuration data and service data in some form of persistent memory to recover from when the server crashes.

Implementation:

Spring cloud config works on the above principles. 

Working implementation of Spring Config Cloud can be found here (Coming soon).

Apart from that just to demonstrate the above watch notification concept using plain java and embedded queue, the source code can be found here (Coming soon).