When you send out requests to the nodes, a non-failing node will return a reasonable response within a reasonable amount of time (with no error or timeout).
Usually, we design a system for high availability. For example, when we say the design target is 4-9’s, it means the services should be up 99.99% of the time. This also means the services can only be down for 52.5 minutes per year.
Note that availability only guarantees that we will receive a response; it doesn’t guarantee the data is the most up-to-date.
The diagram below shows how we can turn a single-node “Product Inventory” into a double-node architecture with high availability.
The diagram below shows how we can turn a single-node “Product Inventory” into a double-node architecture with high availability.
Due to latency when replicating data from primary to secondary, the data read from the secondary may be inconsistent with the primary.
For example, if both nodes need to update the same product, the final state might be unpredictable. Use this architecture with caution!
If we deploy the node on Amazon EC2, which has 90% availability, the double-node architecture will increase availability from 90% to 99%.
Over to you: We’ve covered availability, but do these 3 architecture types also guarantee consistency, or not? Let us know your thoughts!
Over to you: We’ve covered availability, but do these 3 architecture types also guarantee consistency, or not? Let us know your thoughts!
Loading suggestions...