In engineering, redundancy in data1 is the duplication or re-writing of information with the intention of increasing the reliability of the system, usually in the form of storage backup or failsafe mode.
Data redundancy is a common approach to improve the reliability and availability of a system. Adding redundancy increases the cost and complexity of designing a system. However, the rule to follow is that if the cost of failure is high enough, redundancy is an attractive option. Consider that the redundant storage system should not be more expensive than losing the information.
Difference between duplication and redundancy in data
Duplication is when we have a copy of a piece of data but that copy is unnecessary. An example is given in databases; following best practices, data will only exist once in the primary structure. That is, a user's first and last name should only be in one table.
If you save this data in another table, you can say that you have duplicate information. This is only making the database larger and making it take up more space because this data should only exist in one structure in order to avoid confusion. Furthermore, duplication adds a problem; if you want to update this information, you cannot just update it in one place or the information will be inconsistent.
In contrast, redundancy in stored data is the explicit action of creating one or more copies of the entire database. A redundant node is any node that is not strictly necessary for the distributed system to function properly2. In other words, any node that increases the minimum functionality of the system can be said to be redundant.
Redundancy: Storage and security
One way to achieve redundancy is through a redundant array of independent disks or RAID. This comprises a data storage technology in which data is distributed across multiple drives in one of several ways (called RAID "levels"). Another technique is to have one or more extra independent nodes, which represents a distributed system.
While redundancy in data is what allows you to duplicate the components of the design, redundancy itself is not really what is useful. Redundancy doesn't really help you if a redundant node isn't synchronized with the node it was copied from.
How long will that redundant node actually be functional for us? What happens if one of the nodes changes value or status? It turns out that the answer to both questions is the synchronization process. When you keep the nodes in your system synchronized, these redundant copies become much more functional for you.
For example, if a web server or database node is replicated, the end users on the distributed system should have no idea whether they are interacting with a replica or the original node. In fact, they should have no idea that a replicated node even exists.
When this transparency is primarily maintained in a system, node replication provides many benefits:
If a node goes down and you've already added replicas, a replica is much more likely to step in and do the work of the failing node. This makes your system more fault tolerant. Having replicas installed also makes it more available, as there are generally more backup copies to take the place of another node, which means your system shouldn't experience too much downtime.
With more replicas installed, you now have the ability to do more work, handle more requests, and process more data. This makes your platform generally faster, reduces latency and allows the system to handle high throughput of data that needs to be processed/delivered.
Scalability is a big plus when it comes to building a distributed system, but it's not always easy to achieve. With more replicated nodes, it's easier to scale by adding more databases, servers, or services on demand.
Also, it's easier to scale geographically when you can replicate a node and place it on a different continent or in a different country to help scale a large workload at a specific location.
Banking platforms, points-of-sale or any design that cannot tolerate a failure or interruption (mission-critical systems) are the main use cases of redundancy, since redundancy helps prevent the loss of critical data.
A practical example: A store that has multiple point-of-sale stations uses a primary server for customer transactions. If this server fails and the points of sale cannot communicate with the server and there is no data redundancy enabled (temporarily configuring the terminals to work independently, by using locally-copied storage) you will see an interruption in the service and no transactions can be registered.
The idea of incorporating storage redundancy into applications may seem like a challenge. However, with the right technology partner the process is not difficult. Solution providers like KIO Networks are ready to help with this must-have element of technology. We invite you to visit: https://www.kionetworks.com/en/
Notes:
Sources:
https://aaltodoc.aalto.fi/bitstream/handle/123456789/18027/isbn9789526064222.pdf?sequence=1&isAllowed=y
https://www.researchgate.net/publication/273398978_Minimizing_data_redundancy_for_high_reliable_cloud_storage_systems