The choice ̳Virtual synchrony (DC A.13)‘ is especially suitable for systems in
which information evolves extremely rapidly. Applications are executed in
process groups and the processes within the group update each other about
execution progress by sending state updates. Implementing this technique
requires functionality to join process groups, register event handler and send
multicasts to group members. Consistency among information replicas can be
achieved easily, thus virtual synchrony is suitable for systems with high
evolution of information [Wikipedia 2013e].
Relaxing transactional consistency
To follow this tactic the „BASE architecture (DC A.14)‘ can be applied. The
̳BASE (Basically Available, Soft-state, Eventually consistent) architecture‘ is
applicable in systems supporting distributed transactions with optimistic
replication strategy. In this approach replicas of information are sent through a
distributed system via transactions and ̳eventual consistency‘ among the
replicas is achieved by either the update reaches the replica or the replica
retires from service [Wikipedia 2013f]. BASE requires some conflict
resolution functionality and additional system resources in order to find failure in
transactions. The approach is applicable for high performance designs.
Backup and disaster recovery strategy
The following design choices should not be seen as alternative choices to apply
one tactic; the three choices are rather three controls that can help to specify a
disaster recovery plan for the system to be designed [Georgetown 2013].
Therefore all three choices can be applied alongside.
The choice ̳Preventive measures (DC A.15)‘ is aimed at preventing disastrous
events, like data-loss, from occurring. To achieve this data is replicated to have
identical copies in reserve in case the original data gets lost. Consistency
among the data replicas needs to be assured by the design. To minimise risks
the replicas are better stored at different locations that the original data,
preferably in the cloud.
̳Detective measures (DC A.16)‘ aim at detecting or discovering unwanted
events by monitoring indicators for unwanted events, like measured values that
exceed a certain range. This strategy requires an Information Model of those
unwanted events together with their indicators that are used to detect the
unwanted event. The event detection should be operated independent of the
subsystem that is monitored to make sure the unwanted events can be
detected.
The design choice ̳Corrective measures (DC A.17)‘ is aimed at correcting or
restoring systems after disastrous events have occurred. Assuming the
previous two choices have been implemented, meaning the preventive methods
have been applied and the disastrous event has been detected correctly, the
system can be restored to working order again. Backups of system
configurations that have worked correctly before are restored. A configuration
history (Section 4.2.2.8) provides the functionality needed for restoring working