Reliability

I talked about problems that I faced while developing last week but that is no fun to hear me complain. Now I am going to talk about what I have done so far in my client project.

Developing a reliable system

Given that the system I am developing is a competition registration system (we called it CRS for short), it is crucial to capture every significant data regarding the participants. As mentioned before, we utilized the use of webhooks in the WooCommerce web store to send these data straight to my server application. In an ideal world, every single webhook delivery is successful and every single data is successfully captured hence no problem is needed to be dealt with. In the world we live in today, however, nothing is guaranteed to be successful. The system needs to have some form of detection for these kinds of failures and inform us when something goes wrong.

At the moment, the system has two REST API endpoints, one that handles order creation and another that handles order updates. For every single order made in the store, we capture details regarding the customer (or registrant) and the order itself, and for every changes made to the order’s status, we save participant details to the database or send registration slips to the registrant by email or just synchronize the status of the order with the order stored in the database, depending on what the status is. There are three scenarios we need to take into account for:

1. Order creation in the database fails but order is updated,
2. Order successfully created in the database but order fails to be updated.
3. And, both order creation and updates failed.

For the first scenario, the system would just have to inform us that an order is updated but it was not created in the database initially. For the second scenario, as every order is saved to the database, we have a certain threshold starting from the new order where we lookup a previous order at the end of this threshold. If that order is still stuck in processing state, then that is an indication of a problem, so the system sends us a warning on that.

What about checking for missing orders? Each order in the WooCommerce store has their own unique ID, which is sequentially incremented for every new order made. The easiest way to detect these missing orders is for each new order created and save to the database, the system would lookup the previous order in the database and compare that order’s ID to the new order’s ID. If the gap is even slightly larger than one, the system would list the missing orders within the gap. The third scenario is somewhat implicitly handled this.

As of now, the system’s method of informing us these failures is through email, but if time permits, I could integrate Slack with our system to gives us real-time updates. Also, for future versions, we could add a second method of verification for these failures, i.e by interfacing with WooCommerce REST API that will give us a particular order or a list of orders from the store, just to make sure if there is actually a problem. Last, but not least, we can also employ a Machine Learning algorithm to determine the a suitable threshold mentioned earlier, therefore making our system even more robust and reliable.

Valgrind

I am just gonna talk very briefly about a very cool tool that Dr Shawn showed me, and it is called Valgrind. This tool helps to check for memory related issues in your program, such as memory leaks. I think the most fascinating thing about this tool is that it reports which line of code in your program is potentially causing this problem and even gives you a stack trace which leads to that outcome. This is the basic command for executing Valgrind:

valgrind –leak-check=yes path/to/your/program

That is all for this week’s blog. I’m looking forward to finishing up the project soon but I am also terribly nervous when the moment of deploying the system comes. But until then, I have to focus on delivering the product.