Part VII — Architecture Patterns
Chapters 34–37
A pattern is a named solution to a recurring problem, and the naming is most of the value. It lets a team say "medallion" in a design review instead of spending forty minutes re-deriving why raw data should be preserved separately from cleaned data.
The risk is the same as the benefit. A named pattern is easy to adopt without its context, and every pattern in this part has been adopted by organizations that did not have the problem it solves. Data mesh in particular has been implemented, at real expense, by companies with one data team and no domain boundaries to federate.
So each chapter here does three things: states the problem the pattern solves, shows the pattern applied to Kestrel concretely, and names the conditions under which you should not adopt it. The third is the part most pattern writing leaves out.
Chapter 34 is the medallion architecture — bronze, silver, gold — and the progressive refinement of data. It is the pattern with the best benefit-to-cost ratio in this book: nearly free, applies at almost any scale, and makes debugging tractable because it tells you where to look. Kestrel has been using its layer names since Part II; this chapter formalizes what they guarantee.
Chapter 35 is data mesh: domain-oriented ownership, data as a product, self-serve platform, and federated governance. It is a genuine answer to a genuine problem — the central data team becoming a bottleneck as an organization grows — and it is the most misapplied idea in the field. This chapter takes it seriously and is direct about when it is wrong.
Chapter 36 is event-driven architecture: designing around events rather than tables, event sourcing, the outbox pattern, and what changes when the event log rather than the database becomes the source of truth. It is the architectural end state that Chapters 14, 15, and 29 have been approaching from different sides.
Chapter 37 is migrating legacy pipelines, which is the work most data engineers are actually hired to do. Cron scripts, stored procedures, a GUI ETL tool nobody has credentials for, and a spreadsheet that turns out to be load-bearing. The strangler-fig approach, running old and new in parallel, reconciling them, and the political problem of a migration that produces no new features.
What you will have built by the end of Part VII: the Kestrel platform's layers formally specified with guarantees at each boundary, a domain-ownership analysis that concludes honestly about whether Kestrel should adopt a mesh, an event-driven design for the order lifecycle, and a migration plan for the legacy nightly cron scripts that predate the platform.
The single idea to carry out of this part: a pattern adopted without its problem is overhead with a good reputation. For each of these four, be able to state the specific condition in your organization that makes it worth its cost — and if you cannot, do not adopt it yet.