Design a scalable data governance framework balancing autonomy and control
Federated governance balancing autonomy with interop via policy.
Self-serve platform with domain products, auto-catalog, schema contracts, and policy-as-code access in CI/CD.
Centralized manual approval of schemas and access.
What's really being asked
This question evaluates whether you understand how to scale data governance beyond a monolithic data lake by applying data mesh principles. The interviewer wants to see if you can balance decentralized domain ownership with centralized interoperability through automated policy enforcement rather than manual gatekeeping.
The full answer
First, domain-oriented ownership where each team owns its data products end-to-end, including operational and analytical data, rather than handing data off to a central platform team. Second, data as a product thinking, meaning each domain publishes datasets with clear SLAs, documentation, and schema contracts that consumers can discover and trust. Third, a self-serve data platform that provides shared infrastructure for cataloging, schema registry, and access control so domains do not build redundant tooling. Fourth, federated computational governance where policies are defined centrally but executed automatically via policy-as-code in CI/CD pipelines, such as schema compatibility checks, PII tagging, and role-based access controls that run before deployment. Fifth, a multi-plane platform architecture that separates the data infrastructure plane from the data product plane and the mesh experience plane.
The mistakes people make
Proposing a central data platform team that manually approves every schema change or access request. Suggesting a single monolithic schema registry without domain-level autonomy. Ignoring the difference between operational and analytical data. Recommending heavy manual data stewardship instead of automated computational policies. Failing to mention data product SLAs or consumer contracts.
What usually comes next
How would you handle breaking schema changes across multiple downstream consumers? What is your strategy for discovering and classifying sensitive data at scale? How do you measure the health of a data product? How would you migrate an existing monolithic data lake to this architecture over twelve months? What specific tools would you use for the schema registry and catalog, and why?
A concrete example
Imagine a retail company with fifty engineering teams. The inventory domain publishes an events stream as a data product with an Avro schema registered in a centralized but federated schema registry. When inventory pushes a new schema version, automated CI/CD checks validate backward compatibility against all registered consumers. The data catalog auto-ingests metadata, tags PII fields via automated classification, and enforces access policies so only the analytics and finance domains can query pricing data. Governance is federated: a central council defines tagging and access standards, but each domain applies them through code, not tickets.
Interview question
In a scalable data mesh governance model, how should access and schema policies be enforced to balance domain autonomy with interoperability?
- a.Require a central data platform team to manually approve every schema change and access request before deployment.
- b.Assign dedicated data stewards in each domain to manually validate schemas and grant access through ticketing workflows.
- c.Let each domain independently define and enforce its own schema and access policies without central coordination.
- d.Define policies centrally but automate enforcement via policy-as-code checks in domain CI/CD pipelines before deployment.Correct
Why? this is the answer
This reflects federated computational governance, where centrally defined policies are automatically enforced via CI/CD to scale without bottlenecks. Central manual approval is a red flag because it strips domain autonomy and creates unsustainable gatekeeping.
Just read this? Test yourself on what you have been reading.
Read the original → martinfowler.com
- #data mesh
- #data governance
- #system design
- #federated governance
- #platform engineering
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles