CAP Theorem
The CAP theorem (Brewer) states that a distributed datastore can guarantee at most two of: Consistency, Availability, and Partition tolerance. Since network partitions are inevitable in real systems, the practical trade-off in any production design is between consistency and availability. Saying 'we are CP' or 'we are AP' is an architectural commitment, not a slogan — it dictates retry, replication, and failover behaviour.
Concepts that travel with this one.
Architecture rarely lives in isolation — these are the terms that come up in the same conversation.
Eventual Consistency
Eventual consistency is a relaxation of the strong-consistency guarantee: writes propagate asynchronously across replicas, and readers may briefly observe stale state, but the system converges to a single value if writes stop. The CAP-theorem trade-off is throughput and availability under partition. TantraDev uses eventual consistency knowingly — never as a side effect — and always with a documented staleness window.
Horizontal Scaling
Horizontal scaling (scaling out) adds more identical instances behind a load balancer rather than making one instance bigger (vertical scaling). The constraint is whether the workload can be partitioned cleanly — shared mutable state, ordering requirements, or session affinity all push back. TantraDev's first move on a saturated single-server monolith is to find the partition key, not to upsize the box.
Building a system where CAP Theorem is the load-bearing decision?
30 minutes on the phone, one page in your inbox — what to build, what to skip, what it will cost. You keep the audit even if we are not the right fit.