Follow One Data Point
A person presses Buy once. Follow that single fact through the transaction, the write-ahead log, change capture, the event log, raw storage, transformation, a fact table, a warehouse and a mart, until it is one unit inside a number somebody reads out in a meeting.
Read the what one record is panel at every hop, in order. It changes four times along this path, and each change is a place where an aggregate that looks completely reasonable becomes silently wrong. Nothing on this walk fails loudly; if any of it did, this domain would be much easier than it is.
The walk
Twelve hops from a human intent to a rendered tile. Each one states what it promises the next, and what it can quietly fail to deliver.
The user clicks "Buy"
A person, on a phone, with an intermittent connection, presses a button once. They believe they have bought one thing.
- —The connection drops after the request is sent and before the response returns, so the client retries and the intent arrives twice.
- —The user presses again because they saw an error, producing a second intent that is genuinely a second intent — indistinguishable, downstream, from a duplicate.
The second descent: a fact-table row down to bytes in a bucket
§214 asks for “go one layer deeper” on the fact table itself. This is that descent, and it leaves this domain twice on the way down.
You do not need this every day. You need it on the day a query that filters one date reads a year, or a table that holds a modest amount of data takes longer to list than to read. Both of those are answered several layers below the row the analyst is looking at, and neither is visible from SQL. Each step names the domain that owns it properly.
A row in `fct_orders`
What the analyst sees: a row with a customer key, a product key, a date key and two measures.
- —Believing the row is the storage unit, and reasoning about query cost as though reading one row were cheap and reading one column were expensive.
Where to go next
The same path, but with something wrong with it.