ACID Transactions
A transaction is a group of one or more operations that a database executes as a single unit: either every operation in the group succeeds, or none of them do. ACID is the acronym for the four guarantees a database makes about how that unit behaves — Atomicity, Consistency, Isolation, Durability — and it's the vocabulary that lets you say precisely what a database promises instead of vaguely gesturing at "it's reliable."
SQL vs NoSQL
"SQL vs. NoSQL" is really shorthand for a deeper question: how strictly should the database enforce a fixed schema and strong relational guarantees, versus how much flexibility and horizontal scale should it trade those guarantees away for? SQL (relational) databases answer that question one way; the broad "NoSQL" family — which is really several different data models grouped under one negative label — answers it several other ways.
Database Indexes
Without an index, finding a row that matches a condition means scanning every row in the table — a full table scan. An index is a separate, sorted data structure that maps a column's values to the location of the rows that hold them, so the database can jump straight to matching rows instead of reading the whole table. It's the same idea as a book's index: you don't scan every page for a term, you look it up in a sorted list that tells you exactly which page to turn to.
Database Sharding
Sharding splits one logical database into multiple independent pieces — shards — each holding a subset of the data and running on its own machine. It's the database-specific application of horizontal scaling: instead of one machine holding (and serving all queries against) the entire dataset, many machines each hold and serve a slice of it, so total capacity grows by adding shards rather than by buying an ever-bigger single machine.
Data Replication
Replication keeps copies of the same data on multiple machines. Where Database Sharding splits different data across machines to scale capacity, replication puts the same data on multiple machines — and the two solve genuinely different problems: sharding scales how much data you can hold and write, replication scales how many reads you can serve and how well the system survives a machine dying. Most large systems eventually need both, layered together.
Database Scaling
Databases tend to be the hardest part of a system to scale, for a reason called out back in Scalability: stateless web servers can be trivially duplicated behind a load balancer, but a database holds the one copy of the truth, and duplicating that safely is a much harder problem. Database scaling is the progression of techniques for handling more load, roughly in order of how much complexity each one costs.
Database Types
SQL vs. NoSQL frames the decision as roughly one axis — relational structure vs. flexible scale — but "NoSQL" itself covers several genuinely different data models, each shaped around a different access pattern. Knowing which model fits which problem, and naming it specifically, is a stronger interview answer than "we'll use a NoSQL database."
Bloom Filters
A Bloom filter answers one narrow question extremely cheaply: "is this element possibly in the set, or definitely not?" It's a probabilistic data structure — it can return a false positive (say "maybe" for something that isn't actually there), but it can never return a false negative (if it says "definitely not," that's always correct). That one-directional guarantee, traded for a tiny, fixed amount of memory regardless of how large the underlying set is, is what makes it useful.
Database Architectures
Every lesson in this module has covered one piece of a database in isolation — transactions, schema choice, indexing, sharding, replication. A database architecture is what you get when those pieces are assembled into a complete topology: how many nodes, which ones accept writes, how they stay in sync, and what happens when one of them fails. This lesson is a capstone, walking through the standard topologies and where each piece from the rest of this module fits into them.