Please enable JavaScript.
Coggle requires JavaScript to display documents.
4 Distributed Computing Fallacies - Coggle Diagram
4 Distributed Computing Fallacies
The network is reliable
Request or Response
lost during transit.
2a. (For Synchronous message) Retry and Ack
Overload target service
Soln: Exponential backoff
For no response scenario determine if execution has happened at target service or not?
Soln: Idempotent operation
2b. (For Async mesg) Store and Forward
Messaging infrastructure can be a solution
Soln steps
(On Timeout exception,) Log the Error message
Chaos tests
Latency is zero
95-99th percentiles operations are severe
Network Latency as the time it takes from 1 server to another.
Round-trip time
This includes serializing/deserializng and
processing at the server as well.
Soln: Avoid crossing the network
Bandwidth is infinite
Gigabit /sec = 128 MB /sec
60MB/s (as TCP needs half of the bandwidth)
30MB/s (as Serialization & Deserialization)
Soln: Move time-critical data to separate network
The network is secure
Topology doesn't change
Switches, Router, Load Balancer
There is one administrator
Transport cost is zero
The network is homogeneous
CAP theorem
(aka Brewer's theorem)
PACELC theorem
(an extension to the CAP theorem)
In case of network partitioning (P) in a distributed computer system, one has to choose between availability (A) and consistency (C) (as per the CAP theorem), but else (E), even when the system is running normally in the absence of partitions, one has to choose between latency (L) and loss of consistency (C).
A high availability requirement implies that the system must replicate data. As soon as a distributed system replicates data, a trade-off between consistency and latency arises.
Distributed data store can provide
only two of the three guarantees
Consistency
Every read receives the most recent write or an error.
Availability
Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
Partition tolerance
The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.
Fallacies @ Runtime aspects
Fallacies @ Design time aspects