Introduction
Failover - The standby server takes over, when the main server fails.
In this article, I will explain the Failover functionality to be achieved, using WCF concepts. The general idea behind going into Failover is 24/7 availability of the service to the critical client applications. The client application should always be in a position to consume the Backup Service though the Main Service, which is not available due to some reason. Let us discuss this in detail.
Failover
Failover is a method of protecting the Applications/communication from failure, where there is a backup Service. IT automatically takes over when the Main Server fails. In a real world scenario, you can see that ticket booking websites take more time to book the tickets (to get the Server response) during peak hours. The Server takes more time due to Server’s unavailability, or if the number of requests in the queue is higher, or for any other reason/s. Whatever the reason is, the client application should not be impacted, another Server should take it up when the main Server is not available.
![]()
Figure1.0 Work Flow Diagram
In the snapshot, given above, you can find that the client communicates with the main router. It is not aware of the Primary Service or Backup Service. When the router receives the request from the client, it usually tries to process it with the primary Server. If the primary Server is not reachable for any reasons, the main router then automatically tries to connect with the Backup Service 1. If the Backup Service 1 is available, the request would be processed and send the response to the client. If the Backup Service 1 is also not available, it would send the request to Backup Service 2 to get it processed.
The client does not need to worry about the availability of the Servers. The main router will re-route the request to the back-up services and get it processed, if the Primary Servers are not available.
Need for Backup
Let us discuss, in detail, about the need of a back-up service.
Critical Applications Availability
Critical applications are the ones, where large number of users always want to perform many transactions at a time. For example, bank transfers, where a large number of people need to do fund transfers and other transactions as part of their day-to-day activities. If this kind of Application Server gets affected, the impact will be huge. To overcome these issues, Backup Server is always recommended to take care of the client’s transactions, if the Primary Server is not available.
Load Balancing
There are situations when the Service gets more requests/transactions only during the peak time on any single day. Let us take the ticket booking websites. A large number of users will try to book the tickets once the tatkal period gets started. If the Server is not capable enough to process all the requests, the clients will not be able to book the tatkal tickets. To overcome this, the Main Server should load balance the requests to the backup services accordingly. Let's say, if the Primary Server is already processing 1000 messages, the Main Server would reroute the other 1000 messages to the Backup Services. This would increase the processing time and the client’s request will not affect.
Routing Configuration
Let us take the Figure 1.0 as a reference for configuring primary and backup services accordingly. As a first step, create the Primary Service library and the host application. As usual, in the Primary Service library, you can define the contracts and service implementation. Afterwards, create the host application and refer to the Primary Service library, define the Service, endpoint, and host it. In our example, I have done it in self-hosting. If you need an assistance in configuring and hosting the Services, please look at my previous articles Configuring WCF Routing, Hosting in WCF.
Primary Service
![]()
Figure 1.2 Primary Service
From Figure 1.2, you can find that Primary Service is hosted on net.tcp://localhost:8523/PrimaryServiceLib/Service. Afterwards, you need to repeat the same configuration for the Backup Services 1 and 2. In our case, the address of Backup Service 1 and 2 are given below.
“net.tcp://localhost:8524/BackupService1/Service/”,net.tcp://localhost:8525/BackupService2/Service/.
Now, you have successfully hosted the Services Primary, Backup Service 1, and Backup Service 2. Now, it is time to define the Routing Service, which will pass the messages to the appropriate Service, based on availability. As I have already mentioned in my previous articles, we shouldn’t forget this simple sentence “Address the filter and filter end” . It is just a sentence I have framed myself to remember the RoutingServer configuration steps, which are Address, Filter table, Filters and endpoint, As I shown in the Figure 1.3 snapshot configure the Routing Service accordingly
![]()
![]()
Figure 1.3 Routing Service In the filter table named “RoutingInformationTable”, you can find that the MatchAllFilter has been applied and routed to the end point named “PrimaryService_TCPEndPoint”. MatchAllFilter is used to route all the messages from the client to the PrimaryService_TCPEndpoint. You can find other attribute named “backuplists” in the filter element. If the RoutingService find the PrimaryService_TCPEndpoint is not available for some reasons, it can route the messages to the endpoints listed in the BackupServices. If the backup Service 1 is also not available, then it re-routes to back up Service 2 endpoint. So the client will not aware of the Service from which Service his request served.
Summary
Failover functionality is an important feature in Client-Server communication. It is quite natural that Services may stop/not be reachable for any reason. Routing Service will take the client to the different Service (backup) if any of the primary Services are not available. Backup Service will process the request and send it back to the client.