Partial Update (Under the hood)

This article is part of our "Tiger Bridge - Under the hood" series, where we uncover technical details about our product, dive deep into the solutions it offers, and explain which decisions we had to make while designing it.

Dilemma

Similar to the previous topic, we had to decide if we wanted to replicate whole files or just pieces of them when making changes.

Background

The partial update functionality is another sub file operation. The file is viewed as a macrostructure – a database, video file, or a large backup. In such cases, if you make a small update (e.g. adding two records in a database), you would probably not want to replicate the whole file again in order to apply the update. It would be better to just send the delta.

Pros/Cons

A downside to implementing partial update is that it is a complex operation which requires more effort to preserve consistency.

If not done properly, it increases the risk of only some (not the entire) update data being processed in an event of a power outage or another disruption. This can lead to a decrease in integrity. Maintaining integrity in situations like these requires extra operations and makes implementation more complex.

Decision

We implemented the partial update functionality in Tiger Bridge. As with other decisions, our focus was on enabling customers’ mission and time-critical applications to operate at their maximum. We wanted to ensure that integrity of the data will go with our implementation.