Designing distributed systems is no walk in the park. We can liken distributed systems to friendships. There are many people with who you may be friends and communicate on a daily basis. How do you ensure that you keep in sync with your friends in order to maintain healthy relationships? You can’t solely focus on a subset of your group or you’ll risk alienating yourself from the others.
Here’s where CAP thereom comes into play. Coined by Eric Brewer, it focuses on three main domains that distributed system problems can be bucketed into. The theorem states that a system can only provide 2/3 guarantees:
- All executions of reads and writes seen by all nodes be atomic.
- With every request, you should be guaranteed to receive a response.
- After failures, the system should continue to run as expected.
One caveat is that CA is considered a joke because it’s not feasible to achieve strong consistency and a fully highly available system. This would introduce single point of failure in our architecture. There are tradeoffs that you will need to consider before swaying towards one area. Below are the following pairs that you’ll often see systems focusing towards:
CP (Consistency & Partition tolerance)
- Paramount that all data sources reflect the same state.
- Useful for file systems and RDMS to enforce strong consistency.
AP (Available & Partition tolerance)
- You care more about your system being up than synchronisation.
- Useful for social media applications e.g. if I send a tweet, there can be a delay before my followers can read it. This is acceptable.
- Useful for transactional systems e.g. banks. You care more about your system being active as you can process payments subsequently.
When designing distributed systems, it’s a great practice to measure your use cases against CAP. Do you care more about your system being available as opposed to being in sync? You’ll have to do due diligence to decide what tradeoffs will be more viable for your system.