Keeping a Popular Web App Highly Available While Rebuilding It

by Pavel TsiukhtsiayeuSeptember 16, 2010
Learn how Altoros helped to rebuild an outdated software architecture of the web app while retaining the functionality and reducing downtime to seconds.

(Featured image credit)

 

Background

When redesigning web application architecture for one of our customers, we had to pay extra attention to availability. Since the project—an interactive community for childcare providers—was already a popular website, the uptime was crucial for the customer. The web application had to be up and running throughout the whole development and integration process. Even more, the outdated code structure made adding new modules, integration, and testing quite a challenge.

 

Step-by-step code updates

To minimize the downtime when applying the changes, we decided to perform the integration and code updates in stages. Replacing the whole working modules step by step could help to avoid affecting the performance of the entire application.

First, each unit of the existing code was carefully tested to find out how it behaves. This gave us the necessary information on what actions and results we should reproduce.

Second, all the updates and the new code were also completely covered with tests. When a new piece of the code was created, we wrote new tests for it. As soon as all the tests had been passed, the new code was uploaded to staging, where real users and QA engineers tested it in the environment close to the production server. The new module was moved to production after we made sure everything was OK. These step-by-step code updates guaranteed that each new unit functioned properly and would not damage the system.

However, a part of the application wasn’t covered with unit tests by the developer who launched this application prior to our involvement. This resulted in issues with user registrations after adding one of new modules—since we even did not know how the systems should work there and no information on the possible user scenarios was provided. Fortunately, we fixed this problem and created the missing unit tests after the updates were implemented./p>

Initially, the system had about 400 unit tests. After the redesign, it had over 1,000 tests that can be utilized now by other developers willing to add new functionality.

 

Error notifications

However, it’s not enough to pay attention to testing during the implementation process only. When a new feature is added, there are always minor bugs that are very hard to detect. Fortunately, Google and spam bots are great testers. They may visit new pages earlier than real visitors, fill out forms there, and so on. This often leads to discovering situations that a developer could have overlooked.

To improve bug-fixing and react as soon as possible, we made the application automatically send us an e-mail when any performance error occurs. This is an efficient way of tracking bugs when the system is already in production—even if a bug is found by bots.

 

Highly available web application

As a result, the application retained its functionality throughout the whole development process almost without downtime—the latter was limited to just a few seconds. In addition, the customer succeeded in expanding its services further—their team successfully engaged four new cities and two new states in their community.

For more, read the case study.

 

Further reading

 

About the author

Pavel Tsiukhtsiayeu is a full-stack engineer at Altoros. He has solid experience in web apps delivery. Pavel has profound knowledge of both front- and back-end technologies, including Elixir, Phoenix, Ruby on Rails, React, Twitter Bootstrap 4, etc. In addition, he has expertise in leading a practical course on Ruby and Ruby on Rails for junior developers.

The post was written by Pavel Tsiukhtsiayeu, edited by Katherine Vasilega and Alex Khizhniak.