At the fintech startup, we ingested financial data from dozens of sources. News feeds, market data, alternative data providers. The pipelines were my problem as CTO. Every schema change, every quality issue, every “why is this number wrong” question funneled through the same two people.
That doesn’t scale. It barely functions.
Data mesh, as Zhamak Dehghani describes it, is the first framework I’ve seen that names the actual disease instead of treating symptoms. The disease is centralized ownership of something that’s inherently distributed.
The real principle
Data mesh has four pillars. Domain ownership. Data as a product. Self-serve platform. Federated governance. You can read the theory anywhere. Here is what actually matters.
The people who produce data must own it. Not “be consulted about it.” Own it. Define its schema. Guarantee its freshness. Document what it means. Support the teams that consume it.
Everything else is implementation detail.
Why this is hard
Most organizations resist this because it means domain teams need data engineering skills. That’s expensive. It’s also the only thing that works past a certain scale.
I watched this play out firsthand. At the fintech startup, our financial data pipelines broke constantly at domain boundaries. The market data team understood tick data. The NLP team understood sentiment scores. The central pipeline team understood neither. They just glued CSVs together and prayed.
The fix wasn’t better tooling. It was making each team responsible for publishing clean, documented, versioned data products. The moment producers had skin in the game, quality improved overnight.
Where people get this wrong
Three failure modes I keep seeing.
Renaming the central team. Calling your existing data warehouse team a “platform team” changes nothing. If every pipeline still routes through them, you haven’t decentralized. You have rebranded.
Contracts without enforcement. A YAML file describing your data product is worthless if nobody checks freshness, schema compatibility, or whether the docs are current. Contracts need automated checks or they are fiction.
Premature adoption. If you have one data team serving three consumers, you don’t need data mesh. You need that team to do its job well. Data mesh solves scaling problems. If you aren’t at scale, you’re importing complexity for free.
When it fits
You probably need data mesh thinking when requests to your central data team take weeks instead of days. When pipeline incidents trace back to domain knowledge that nobody on the data team has. When producers and consumers of the same dataset have never spoken.
You don’t need it if your team is small, your domains are fuzzy, or you’re still figuring out what your product even is. I’m in an EF batch right now building Decloud from scratch. We don’t need data mesh. We need a Postgres table and some discipline.
The real blocker
Data mesh asks domain teams to take on work they didn’t sign up for. That’s a management conversation, not an architecture decision. If leadership won’t staff domain teams with data skills and hold them accountable for data quality, no framework will save you.
The technology is the easy part. Ownership is the hard part. Always has been.