Databases
ACID
The guarantees that make relational data trustworthy: Atomicity (all or nothing), Consistency (constraints always hold), Isolation (concurrent transactions do not corrupt each other) and Durability (committed data survives a crash). They are why banks run on SQL. Distributed systems often relax them toward BASE and eventual consistency to gain availability and scale.
Purpose
ACID names the four guarantees that make a transactional database trustworthy: Atomicity (all or nothing), Consistency (constraints always hold), Isolation (concurrent transactions do not see each other's partial work) and Durability (committed data survives a crash). Together they let application code assume the data is never half-written.
When to Use It
Anywhere correctness of money, inventory or state matters more than raw throughput — which is most systems of record. It is why banks, marketplaces and booking systems sit on relational databases.
Trade-offs
Full ACID over a distributed cluster is expensive — coordination costs latency and availability — so large-scale systems often relax toward BASE (basically available, soft state, eventually consistent) for the data that tolerates it, keeping strict ACID for the data that does not.
Implementation
In a single-node relational database, ACID arrives via write-ahead logging, locking or MVCC, and constraint enforcement — your job is mostly to use transactions correctly and declare real constraints (foreign keys, uniqueness, checks) instead of enforcing them only in application code. Across services, accept that ACID stops at the database boundary and design with sagas or idempotent steps.