Skip to content
LakeBench
ProblemsCommunityPricing
Sign inStart practicing
Back
  1. System Design

System design interview

Data Mesh Architecture

HardPro55 min read

Design a federated data platform where domain teams own data products; define central platform duties, interoperability, and governance.

system-designdata-meshgovernancearchitecture-patterns

Interview framing

Design a data mesh: payments, search, and logistics each own data as a product. What does the central platform team provide? How do you ensure interoperability and governance?

This is an advanced organizational architecture question. Tools matter, but ownership and contracts matter more.

Background from first principles

A company grows past a single data engineering team. Every domain files tickets: "need a new table," "fix this join," "add this column." The central team becomes a queue. Delivery slows. Domains ship shadow pipelines. Quality varies. Consumers drown in undocumented dumps.

The opposite failure also exists: every team publishes raw data with no docs, no SLAs, and three different meanings of customer_id. Autonomy without contracts is chaos.

Data mesh tries to fix ownership:

  • Domains own data products (discoverable, trustworthy datasets with SLAs).
  • A central platform provides self-serve infrastructure and paved roads.
  • Federated governance sets shared rules without rebuilding every pipeline centrally.
  • Interoperability standards make cross-domain joins possible.

Mesh is organizational first. Buying a catalog vendor is not mesh by itself.

Full problem statement

Sketch organizational and technical mesh for a company with multiple domains past the single-team bottleneck. Cover:

  • Domain teams publishing discoverable data products.
  • Central platform capabilities.
  • Cross-domain consumers finding and trusting products.
  • Governance for PII, quality SLAs, and interoperability.
  • Avoiding both central bottleneck and total chaos.

What "good" looks like

You tell the ticket-queue story and the chaos story. You define data as product. You separate platform duties from domain duties. You name catalog, contracts, identity standards, and quality SLAs. You admit mesh overhead is wrong for a tiny company. You answer breaking schema changes and global KPI ownership.

Clarifying questions

  • How many domains and how mature are engineering practices?
  • Existing central warehouse politics?
  • Regulatory environment?
  • Who funds shared compute and platform staffing?
  • Are domains staffed with analytics engineers, or only app engineers?

Scale prompts

  • Number of domains and data products.
  • Expected consumers per product.
  • Cost allocation for shared lakehouse compute.
  • Change failure rate for schema breaks.

Out of scope

  • Claiming mesh is only a Snowflake sharing feature.
  • Designing every domain's internal microservice map.
  • Ignoring identity and semantic consistency problems.

Expanded company story

Payments, search, and logistics each have engineering managers, on-call, and roadmaps. A central data team of eight cannot build every dataset. Yet finance needs cross-domain revenue and delivery KPIs that no single domain owns alone.

You must design mesh so domains ship products quickly while a platform team ships paved roads, and a governance model prevents semantic drift.

Concrete deliverables interviewers expect

  • A diagram of domains + platform + catalog.
  • A definition of a data product (SLA, owner, schema, access).
  • Examples of central standards (PII tags, naming, compatibility).
  • A plan for shared identifiers.
  • Honesty about company size: mesh is heavy for a 10-person startup.

Out-of-scope reminders

Do not spend the whole interview debating vendors. Do not ignore org change management. Do not promise mesh without staffing platform engineers.

First principles before "mesh"

Data platforms fail in two symmetric ways:

1. Centralization bottleneck: everything waits on one team. 2. Decentralization without contracts: everything is published, nothing is trusted.

Mesh is a deliberate middle path emphasizing domain ownership plus platform enablement plus federated governance. If you cannot explain those three legs, you are not ready to recommend mesh.

Problem statement expanded

"Payments, search, and logistics must own discoverable data products. Design what the central platform team provides, how consumers find and trust products, and how governance keeps PII and interoperability under control without forcing every pipeline back through a central ticket queue."

What good looks like in the room

  • Organizational diagram first, tools second.
  • Definition of data product with SLA and owner.
  • Platform capability list that sounds like an internal product.
  • Interoperability plan for identifiers.
  • Clear "not for small teams" caveat.
  • Answers for breaking changes and global KPIs.

Clarifying questions (expanded)

  • Domain count and staffing of analytics engineers.
  • Current central warehouse politics and shadow pipelines.
  • Regulatory bar (PCI, GDPR, HIPAA-like needs).
  • Funding model for platform.
  • Existing catalog or none.

Scale / estimation prompts

  • Products per domain.
  • Consumers per product.
  • Expected schema change rate.
  • Platform team size vs domain count (too few platform engineers kills mesh).

Out of scope

  • Vendor checkbox tours.
  • Full org redesign of all product teams.
  • Promising zero central coordination for company-level metrics.