Data Mesh: Data Analytics for Engineers
summary
Argues that teams own analytical data and use existing tools to act: operational Kafka events are streamed into BigQuery, cleaned with SQL and DBT, cataloged and monitored, and exposed as documented data products under federated governance. An e‑commerce case shows half of “no‑find” cancellations reappear within seven days, equating to ~100,000 euro/month saved by waiting seven days — the team implements the delay and the metric improves. Recommends policy‑as‑code, self‑serve platforms, and minimizing cognitive load.
AI-written summary · about
chapters (26)
- 0:00Introduction
- 1:04Empty backlog discovery
- 3:09Solving no-find issues
- 6:39Data analytics for engineers
- 7:21What is Data Mesh
- 9:07Why central teams fail
- 10:34Domain-driven design
- 12:23Data Mesh principles
- 13:08Domain ownership core
- 14:11Data as a product
- 15:35Self-serve platform
- 16:18Federated governance
- 17:00Data Mesh e-commerce
- 19:29Reference architecture
- 21:41Domain team duties
- 23:24DBT for quality
- 24:07Analytics tools
- 25:34Creating data products
- 27:20Connecting products
- 27:41Governance standards
- 29:52Governance group
- 31:20Full stack expectations
- 33:48Cognitive load
- 37:02Implementation tips
- 37:48Resources
- 38:52Fitness test
related talks
39mData Mesh in the wild
54mData Mesh in Practice
41mModern Data Stack: Optimising and Scaling Data in a Tech Company
42mFour Years of Data Mesh in Practice
37mMetadata Automation in the Data Mesh
25mData Demons: Unleashing Chaos or Driving Performance?
42mFour Years of Data Mesh in Practice
56mData Unleashed: A Developer's Perspective on Navigating the Architecture Maze