A trade-off in a real system is chosen from what the product accepts, not from the CAP theorem.
Zanzibar cannot let go of consistency, because it needs causal ordering. It cannot let go of availability, because everybody is using it. It cannot let go of partition tolerance, because the system has to be distributed.
CAP is for generic systems. What is acceptable in the domain defines how a system is built.
- A ledger for payments keeps latency, consistency and availability. A person's balance is the complex computation, and it is managed when the day ends.
- An authorization system may accept a delay in a write request, such as a password change that takes three minutes.
- Zanzibar is read heavy. Facebook's Memcache was built for 100 read requests to one write request, and Twitter's write heavy copy did not work out.
Read heavy is said of the authorization list. A team can keep editing a document, while writes to its authorization list are much lower than the reads.