Glossary
CAP Theorem
A principle of distributed systems: during a network partition a system can guarantee either consistency or availability, but not both. You can only pick two of consistency, availability and partition tolerance.
General definition
The CAP theorem, formulated by Eric Brewer, states that a distributed data system can provide at most two of three guarantees at once: Consistency (every read sees the most recent write), Availability (every request gets a non-error response), and Partition tolerance (the system keeps working even when the network drops messages between nodes).
Because network partitions are a fact of life in any real distributed system, partition tolerance is not optional. So in practice the theorem forces a choice during a partition: stay consistent (reject or delay requests that cannot be confirmed) or stay available (answer with possibly stale data). Systems are often labelled CP or AP based on which they favour.
- CP systems favour correctness, common for databases, ledgers and systems of record
- AP systems favour uptime, common for caches, presence and chat-delivery layers
- The PACELC extension adds the latency-versus-consistency trade-off for when there is no partition
In the Ethora ecosystem
Chat and messaging platforms live this trade-off constantly. Message delivery and presence usually favour availability, so a user stays online while messages queue and sync when a partition heals, whereas a system of record like a compliance audit log favours consistency. Ethora is designed around this reality with durable message storage, acknowledgements and automatic reconnection so nothing is silently lost.
For self-hosted and dedicated deployments the CAP trade-offs are yours to tune through replication, quorum, backups and high availability topology. Cloud or self-hosted, the platform aims for high availability of messaging while keeping the audit trail consistent.
