Where we are
Session 1 gave you four meters. Tonight is entirely about the fourth one, blast radius, because it is the meter that is decided by organisational shape rather than by technology, and it is the one that has the single cheapest fix on the whole board.
★ What you walk out with tonight. A written contract for one real table, a boundary map that says which team owns which piece of Daybreak, and the ability to answer "whose fault is this" before the incident rather than during it.
LiveThe uncomfortable framing: your architecture will look like your org chart2 min▶
Conway's observation from 1967 has aged better than almost anything else in this field: organisations design systems that mirror their own communication structure. It is not a warning, it is a prediction, and it is usually correct.
The practical consequence for you: if two teams have to talk every time a column changes, you have not drawn a boundary, you have drawn a line on a diagram. A real boundary is one where the other side can change freely inside it and you will not find out, because nothing you depend on moved.
That is what a contract is for. It is not paperwork. It is the definition of what "inside" means.
Three couplings, and only one of them is the one people talk about
7 min liveEveryone knows about schema coupling. It is the one with the error message. The two that actually cost you money are the two that fail silently.
LiveHow to find a boundary that is actually there4 min▶
Draw the line where change frequency and ownership agree. Two tests, both quick:
- The change test. If a change on their side requires a change on yours in the same week, you are inside one boundary pretending to be two. Either merge them or make the interface narrower.
- The pager test. When this breaks at 04:00, who gets woken up, and do they have the access and the knowledge to fix it? If the answer is "we wake up the wrong person and they escalate", the boundary is drawn in the wrong place. Ownership is not who wrote it, it is who is woken up.
Checkout owns orders and order_lines. Analytics owns everything downstream of the extract. The boundary is the extract. Checkout may add columns, change indexes, reshape internals and never tell analytics. What it may not do is change the meaning, the type or the presence of the five fields it publishes. That is the whole deal, and it fits in a paragraph.
Dehghani's data mesh argues the same thing from the other end: the domain that produces the data should own its quality, because they are the only people who know what it means. You do not need the whole mesh to take that one principle.
Change the divisor and the same source data gives a different "average monthly revenue". Nothing errored, nothing was renamed, and two teams now have two numbers. That is semantic coupling in nine characters, and it is why a contract has to carry the definition and not just the type.
What belongs in a data contract, and where it is enforced
6 min liveA contract is not a document. A document that nobody executes is a wish. A contract is a file in the producer's repository that can fail their build, and everything else about it is detail.
Checkout renames order_total to gross_total. Their tests pass. They ship at 16:20.
The nightly load runs at 02:00 and writes nothing. Cron reports success, because cron ran the job and the job exited. At 08:40, 34 of 42 downstream assets are wrong or empty, and the person who finds out is a finance analyst, not an engineer. Three days of investigation lands on a team that has entirely forgotten shipping it.
Checkout renames order_total to gross_total. Their build goes red at 16:04.
The failure message names the contract, the consumers, and the notice period. They add the new column alongside the old one, ship, and open a deprecation with a date. Nothing downstream moved. Total cost: sixteen minutes, paid by the team that made the change and can actually fix it.
LiveWhich schema changes are safe, and which are lies4 min▶
| Change | Safe? | Why |
|---|---|---|
| Add a nullable column | ✓ | Nothing that exists depends on it. The cheapest kind of evolution |
| Widen a type, int to bigint | ✓ | Every existing value still fits and still reads |
| Rename a column | ✗ | Not a rename to a consumer. It is a drop plus an add, and the drop lands first |
| Narrow a type, string to int | ✗ | Some existing value will not fit, and you will find out which one in production |
| Add a NOT NULL column | ✗ | Every historical row is now in violation of a rule you just invented |
| Change a unit or a definition | ✗✗ | The worst one. Types match, loads succeed, and every number is wrong |
The safe pattern for anything in the second half of that table is expand then contract: add the new shape, write both for a notice period, migrate consumers, then remove the old one. Published guidance commonly puts that notice period at 90 days or more, because data consumers have long release cycles and a dashboard nobody owns will not be updated in a fortnight.
Self-studyEnforcement: where the check actually runs4 min▶
Three places, in increasing order of usefulness:
- In the consumer's pipeline. You validate on read and fail your own job. Better than nothing, but you have caught the break after it shipped, and the cost is entirely yours.
- At the boundary, on write. A schema registry or a validation step rejects non-conforming data. Now bad data never lands, but the producer still found out late.
- In the producer's CI, before merge. A compatibility test that simulates consumer behaviour against the proposed schema. The build goes red on their branch. This is the one that changes behaviour, because it moves the cost to the moment and the team where it is cheapest to fix.
None of this requires a platform. A contract can be a YAML file in the producer's repo plus a CI job that reads it. Teams reach for a vendor here far earlier than they need to, and the vendor does not solve the part that is actually hard, which is getting the producer to agree the file is binding.
Write the contract for Daybreak's orders extract
★ 22 min · everyone buildsOne table, five published fields, six blocks. You will write it in prose first, because a contract you cannot say out loud is a contract nobody will honour.
Fields. order_id, customer_id, order_total_cents, currency, placed_at. Five, not fifty. A contract that publishes every column you happen to have is a contract you can never change.
Meaning. One sentence each. "order_total_cents is the amount charged to the customer at checkout, before refunds, in the smallest unit of the order currency." That sentence is what stops the finance argument.
Owner. The checkout team, their rota, their channel. Never a named individual, because individuals leave and contracts do not.
Quality. order_id unique and never null. order_total_cents between 0 and 5,000,000. placed_at never in the future. Row count within 40 percent of the trailing 7-day median, which catches the empty-load failure that types never will.
Delivery. "Landed by 05:10 on every business day." Without this line, a producer who becomes 90 minutes slower has broken nothing, and your 07:00 dashboard is simply wrong.
Notice. Breaking changes get 90 days and a named migration path. Additive changes get none, which is the incentive: make additive changes easy and breaking ones expensive.
List the five fields you would publish for a table you actually own. Not the columns that exist - the ones you are willing to promise. Most people's first list is too long by half.
Write the meaning sentence for the one that has ever caused an argument. Usually it is the money one, and usually the argument is about refunds, tax, or currency. Write the sentence that ends it.
Write one quality rule that is not a type check. A row-count band, a null-rate ceiling, a range. Type checks catch the loud failure. This catches the quiet one.
Write the delivery promise with a clock time in it. Then go and find out whether it is currently true, because roughly half the time it is not and nobody knows.
Now the blast-radius meter below. It starts at Daybreak's current 82 percent - a change anywhere upstream reaches almost everything. Switch on contracts first and watch what one lever does.
Then switch on the other three isolation levers. Notice that contracts alone is worth more than all three of the others put together, and it is the cheapest line on the bill at $60 a month. This is the most lopsided trade in the entire course.
Switch on "stream everything" last. Blast radius goes up, not down. More moving parts is more surface. Session 3 explains when that price is worth paying and session 5 makes you pay it.
If you take one thing from tonight. Move the failure to the producer's build. Everything else in this session is detail around that single structural move, and it is worth $60 a month and 34 points of blast radius.
Before session 3
25 min- Write the six blocks for one real table you consume. Not one you own - one you depend on. The gaps you cannot fill are exactly the questions to take to its owner.
- Find your last silent failure. Search your incident notes or your memory for a time a number was wrong for more than a day. Classify it: schema, semantic, or operational. It will almost never be schema.
- Test one delivery promise. Pick the table your morning report depends on and find out what time it actually lands, for the last 14 days. Compare that to what everyone believes.
- Ask one producer the notice question. "If you had to rename a column we use, how much warning could you give us?" Their answer tells you whether you have a boundary or a hope.
- Add the boundary map to your design doc. Two or three boxes, and on each arrow the five fields that cross it. Session 3 decides where the data goes once it has crossed.
Three questions
Clear all three and session 2 gets stamped in your passport.
1 · Which coupling failure typically costs the most, and why?
A schema break is loud and found in minutes. A definition that quietly starts including refunds passes every type check, loads cleanly, and is discovered by finance in a board pack. Loud failures are the affordable ones.
2 · Where should a data contract be enforced for it to actually change behaviour?
Validating on read means you caught it after it shipped and the cost is yours. A doc is a wish. The build going red on the producer's branch puts the cost at the moment and on the team where it is cheapest to fix, which is the entire point.
3 · Which of these is a safe schema change to make without notice?
Additive and nullable breaks nothing that exists. A rename is a drop plus an add from the consumer's side. Option C is the worst change on the list: types match, loads succeed, and every number is off by a factor of 100 until somebody notices.
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map. Certificates, videos and assessments stay with the official providers.
Session 2 cheat sheet · pin this
You have drawn the lines and written what crosses them. Session 3 decides where the data lands once it has crossed - row store, column store, lake, stream - and introduces the trade this whole course circles: every decision that makes the dashboard fast makes the data older, and you have to say which one you are buying.