Balancing Timeliness and Accuracy in Software Architecture
Navigating event-driven architecture for real-time updates
Recently our engineer asked me a question.
Why do we need to periodically get the latest state via API while we design the event-driven architecture, in addition to relying on asynchronous events for data synchronization?
If we need to get the latest status periodically, then why not just synchronize the data through the API completely?
This is a good question, but before answering this question, let’s consider what our system requirements are.
Suppose we want our clients to see the latest status as much as possible, and we can only allow a maximum delay of 5 minutes.
How would we design the system to synchronize the status through events? First, we would trigger a corresponding event at the point of addition, modification, or deletion of the original data, and then synchronize the state of the original data to our system based on the event. This design ensures clients can see the latest status.
On the other hand, if we need to synchronize the raw data via the API, then we must start a periodic task, such as a crontab, every five minutes, and then periodically download all the raw data back via the API.
Both approaches meet our system needs, but the former is much lighter than the latter, until a problem occurs.
Problems of Asynchronization
The biggest problem with asynchronous events is we cannot ensure the order of the events (unless we add ordering identifiers to the event design). So it is possible that two close updates arrive in the opposite order, resulting in inconsistent data.
For example, the original data is value = A. In a short period of time, it is changed to B and then to C. However, if the order of arrival of the events is such that C arrives before B, then the client will see the result as value = B (instead of value = C).
In addition, asynchronous communication without a proper handshake process can result in event loss, which again can produce inconsistent data.
For these reasons, we often include additional mitigation via the periodic checking mentioned at the beginning. This leads to the question at the beginning, why don’t we just synchronize everything through the API?
The answer is simple, because we are comparing two completely different requirements, i.e., timeliness and accuracy.
Timeliness and accuracy are the two ends of the spectrum.
Under the fixed cost premise, we can’t ask a system to be both real-time and accurate, there must be a trade-off. Costs here include many items, such as development and maintenance costs, hardware costs, transfer costs, and so on.
When we want to achieve high timeliness, we sacrifice accuracy. But if we want to maintain a certain level of accuracy, then we move a little bit to the other end of the spectrum, i.e., periodic checking.
This is why in a distributed architecture it is better to have a BASE rather than an ACID. The E of BASE is eventual consistency, we make sure that the data will be consistent in the end, but how fast is that end? It depends on how many compromises we have to make.
Conclusion
In a software architecture, similar trade-offs occur in various scenarios.
In this case, we end up choosing timeliness over accuracy, but there may be specific scenarios where we need accuracy over timeliness, e.g., a financial reporting system.
In this case, there are two common design patterns for financial reporting systems.
- Monthly report dashboard
- Takes a while to output reports
In the first pattern, we sacrifice granularity for report presentation efficiency. On the other hand, in the latter pattern we choose to utilize additional computation time in order to achieve report accuracy. These design patterns are the result of trade-offs.
There is no one-size-fits-all solution that can be applied to all scenarios, so we need to be careful to identify the non-functional requirements behind the functional requirements when designing the architecture in order to get things right.