Redundancy and Enabling Business Continuity

Whether an outage occurs due to a transient error or a regional failure, ensuring continuity can take different forms. For highly critical applications, data, and files, having a good business continuity plan in place helps business functions keep carrying forward. Normally, business continuity is managed as a separate function but ultimately contributes to a larger disaster recovery plan for the organization.

A common scenario where having a business continuity plan helps is when there’s an outage related to office documents or functionality. Many companies have a shared or distributed file system where spreadsheets and documents are often stored, and when shared documents are unavailable to users, it can impact a business’s daily work effort. While many online services, such as Google Docs and Microsoft 365, can offer a much more durable means of managing and accessing critical documents, even those services can fall victim to outages.

Another common scenario is that of an internal application that’s used by a group of employees: should that application get knocked offline, it could impact productivity. If that application is built in a way that doesn’t account for application data redundancy (and perhaps even infrastructure redundancy), an outage could turn into something much more impactful. Keeping factors such as unexpected downtime in mind when designing an application is something that’ll serve us well once the application is live.

Event retries and continuity

Because there are no examples of either scenario that would come into play with our application, we instead look to areas where redundancy would benefit us. In the last section, we looked at software patterns that can help manage resiliency aspects as well as perform different actions based on the success or failure of those policies. Next, we can examine how to augment the resiliency policies with redundancy in the equipment service:

1. First, let’s open the equipment domain solution in Visual Studio. The area of interest we’ll be taking on is the publisher responsible for logging turnstile usage. Navigate to the Command API project and open the TurnstileController file.

2. We’ll see two methods at the bottom of the class addressing the passenger ingress and egress events for the domain. Here’s where the policy calls will be implemented. We do need to create the retry policy first, so we’ll be adding the following code to the TurnstileController constructor: