2.2.2 A Framework of Functional Requirements
Course subject(s)
2: Functional Requirements
Which Functional Properties Do We Expect?
After many years of using computers and smartphones, many develop an intuition about what these computer systems provide. We also expect that components of the same computer system find each other, by identifier or name, and can communicate easily.
We also expect that the system provides a clock and implicitly that the clock is synchronized for all system components; in other words, acting ‘at the same time’ (synchronously) is trivial for components in a computer system.
Similarly, components should trivially reach consensus, that is, can easily agree on a single value, such as the maximum value across the values stored by all components or which component has received the most votes in the last election. (Surprisingly, real-world elections also struggle with this issue like distributed computer systems.)
Last, for this Module, we expect the data to which multiple components write to show consistency, meaning simplified, that if some components modify the data, afterward all components can read the result and agree it is correct.
Distributed systems counter all these intuitions. Because the machines hosting components of the system are physically distributed, the laws of physics have an important impact: the real-world time it takes for information to get from one component to another can be orders of magnitude higher than it normally takes in the computers and smartphones we are used to. This real-world information delay changes everything. Components in distributed systems cannot easily name or communicate with other components. Distributed systems cannot easily achieve clock synchronization, consensus, or consistency. Instead, all these functions require specialized approaches in distributed systems. These approaches are the focus of this module.
How Do Clock Synchronization, Consensus, and Consistency Relate?
Focusing on clock synchronization, consensus, and consistency, at first glance they seem very different from each other. Yet, they each try to get multiple components in a distributed system to agree on a particular value. This forms the basis of our conceptual framework for these functional requirements.
Figure 1. Comparison of functional requirements.
Framework for clock synchronization, consensus, and consistency in distributed systems (Figure 1). We observe that clock synchronization focuses on an agreement between components about the time, which is a single, numerical value, which changes continuously but unidirectionally (it only increases if one counts the elapsed number of milli- or microseconds since a commonly agreed start time, as computer systems do) and monotonically (with the clock frequency). We also observe a synchronized clock enables establishing a happens-before relationship between events recorded in the system; even without a physical clock, if we can otherwise establish this relationship, we have the equivalent of a logical clock. Using the happens-before relationship between any two events, we can create a total order of these events.
Similarly, we observe consensus focuses on any value, so unlike the clock not only numerical (albeit, all data in a computer is encoded in binary numerical codes, so there are ways to convert any value stored by a computer into a numerical value). More importantly, the value subject to consensus does not need to change as clocks do; in fact, it may not even change at all. Consensus may focus on a single value but, by reaching consensus repeatedly, can also enable a total ordering of events but such an approach is expensive in time and resources.
Finally, consistency focuses on any value from the many included in a dataset, creating a flexible order. Consistency protocols in distributed systems define the kind of order that can be achieved, for example, total order, and, more loosely, when the order will be achieved, for example, after each operation, after some guaranteed maximum number of operations, or eventually. Using consistency protocols to order events in a form weaker than total ordering, and even some discrepancies between how different components see the values in the database, are useful for different classes of applications because they can often be achieved much quicker and with much more scalable techniques.
Modern Distributed Systems by TU Delft OpenCourseWare is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Based on a work at https://online-learning.tudelft.nl/courses/modern-distributed-systems/