Concepts
Data modeling driven by access patterns
Intuition
Think about how to organize a library: before deciding where each book goes, you ask what questions visitors will ask most. If almost everyone asks 'what are the last books I borrowed', it is worth keeping one record per loan, with the title already written down, instead of sending the visitor to check the general catalog on every line. Two questions help: 'which screens and queries does the system need to answer?' and, for each piece of information shown, 'is it today's value or the value from the moment the fact happened?'. The data design comes from the answers, not from an abstract diagram.
How it works
The starting point is to list the access patterns: the reads and writes the system performs, with the frequency of each. Normalization (Codd's normal forms) stores each fact in a single place and links tables by keys; this avoids update anomalies, but a read may require joins. Denormalization writes a copy of the data next to whoever reads it, which shortens the read at the cost of more space and of having to keep the copy consistent. Within a single database, the primary key identifies the row and the foreign key guarantees the reference; between databases of different services there is no foreign key and no join, so the reference is just a stored identifier, and fetching a value from the other side is a network call per item or per batch. The index is chosen from the read query: for 'a customer's items, most recent first', a composite key of customer and date, in descending order, reads only the needed slice instead of scanning the entire table. For each displayed value, you decide between storing the value as of the time of the event (for example, the price paid, copied into the order item at purchase time) or referencing the current value. The value as of the event never needs to be updated, because it describes a past fact that does not change; a copy that must follow its source (such as a product name that must reflect the catalog), on the other hand, causes write amplification: every change at the source forces an update of all the copied rows, and the cost is changes per day multiplied by the number of rows affected per change. The choice between copying and referencing is justified with this calculation, compared against the database's capacity and the screen's time budget. The Dynamo paper records the same logic at the extreme: Amazon's services needed only key-value access by primary key, without the full relational model or complex queries, and so the key has to be designed for the read you want to perform.
In practice
In Dynamo-style databases, such as DynamoDB, the AWS documentation explicitly recommends modeling from the access patterns: first the queries, then the partition key, the sort key and the secondary indexes that serve them, accepting duplicated data. In relational databases, the classic material on normal forms (Codd) and on when to denormalize for read performance asks the same question by another route. In practice, you store the value as of that time in history, invoices and orders, and reference the current value when the screen needs to show the current data and the copy would have to follow a source that changes frequently; if changes at the source grow to the point where updating the copies weighs on the database, that is the signal to swap the copy for a reference.
Use it in a design
Practice the cases that rely on this concept in the System Design school.