Vetora logo

Foundations

Core building blocks and mental models every system designer needs.

Concepts

CAP TheoremP0

The CAP theorem states that a distributed data store can guarantee at most two of three properties -- Consistency, Availability, and Partition Tolerance -- during a network partition. Understanding CAP is essential for choosing the right trade-offs when designing distributed systems.

PACELC TheoremP0

PACELC extends the CAP theorem to cover system behavior when there is no partition: during a Partition choose Availability or Consistency; Else choose Latency or Consistency. This model captures the trade-offs that dominate everyday distributed system design.

ACID vs BASEP0

ACID and BASE represent two contrasting philosophies for data consistency in databases. ACID guarantees strict transactional correctness; BASE accepts eventual consistency for higher availability and scalability. Understanding both is essential for choosing the right database model.

Fallacies of Distributed ComputingP0

The eight fallacies of distributed computing are false assumptions that developers make when building networked systems. First articulated by Peter Deutsch at Sun Microsystems in 1994, these fallacies remain relevant in cloud-native architecture and explain why distributed systems are fundamentally harder than single-machine programs.

Latency Numbers Every Engineer Should KnowP0

A 2026-updated reference of the latency numbers every engineer should internalize -- from L1 cache hits to cross-continent round trips. These numbers form the foundation of back-of-envelope capacity estimation and inform every level of system design.

Little's LawP0

Little's Law (L = lambda * W) relates the average number of items in a system to the arrival rate and average time each item spends in the system. It is the foundation of capacity planning, thread pool sizing, and queue depth estimation in distributed systems.

Reliability, Availability, and DurabilityP0

Reliability, availability, and durability are three distinct properties of a system that are often confused. Understanding their precise definitions, how they compose across service dependencies, and how to measure them with SLAs is essential for designing systems that meet business requirements.