Building Data Products

Chapter 5. Architecting Data Products

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 5th chapter of the final book. Please note that the GitHub repo will be made active later on.

If you’d like to be actively involved in reviewing and commenting on this draft, please reach out to the editor at [e-mail].

Data products do not magically become “products” because we put the word in a slide deck. They become products because they are designed, architected, and operated as such. That means making deliberate architectural choices: where logic lives, how responsibility is split, how trust is enforced, and how the system behaves when (not if) something goes wrong.

This chapter is about those choices. Not vendor diagrams, not reference architectures carved in marble, and definitely not “just add governance.” Instead, you will look at practical architectural patterns that make data products active: self-aware, observable, enforceable, and evolvable. Architecture here is not about boxes and arrows for their own sake; it is about enabling conversation between systems, teams, and eventually machines.

To keep ourselves honest (and sane), we will rely on a lightweight architectural lens, progressively zooming in only when it adds value. The goal is simple: help you design ...