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

System design interview

Medallion Architecture (Bronze, Silver, Gold)

MediumFree75 min read

Design a lakehouse with Bronze (raw), Silver (cleaned), and Gold (business aggregates), including tier boundaries and consumers.

system-designmedallionlakehousearchitecture-patterns

Interview framing

You are designing a medallion lakehouse in a mid-level DE interview. The interviewer wants Bronze (raw), Silver (cleaned), and Gold (business aggregates), plus clear boundaries and consumer rules.

They are testing whether you understand that a lake without contracts becomes a swamp, and whether you can explain replay, quality gates, and who is allowed to query what.

Background from first principles

A data lake is cheap object storage filled with files. Anyone can dump JSON. Anyone can query it with a Spark job. That flexibility is useful. It is also how companies destroy trust.

Without layers and ownership:

  • Analysts build dashboards on raw dumps.
  • A producer renames a field.
  • Revenue silently zeros out.
  • Leadership stops believing "the lake."

Medallion architecture is a social and technical contract. Raw stays raw so you can recover. Cleaned data is curated with schemas and keys. Business numbers live in Gold with owners, tests, and stable names.

Bronze, Silver, and Gold are not magic Databricks trademarks you must invoke. They are three jobs for data at different distances from source truth and business meaning.

Analogy

Think of a professional kitchen.

  • Bronze is the delivery dock: crates arrive labeled, you do not cook yet, you keep the packing slips.
  • Silver is mise en place: washed, cut, typed ingredients ready for recipes.
  • Gold is the plated dish: intentional, consistent, what the diner (BI, exec dashboard) should see.

If diners wander into the dock and cook from crates, food poisoning is on you.

Full problem statement

Design a lakehouse with:

  • Bronze: raw, append-only, recoverable.
  • Silver: parsed, typed, deduplicated, conformed entities or events.
  • Gold: business marts and KPIs for BI and product metrics.

Define:

  • Boundaries between tiers.
  • Who may read each tier.
  • Quality gates between Silver and Gold.
  • How replay works when Silver logic changes.
  • How schema evolution and PII rules apply.

Context: multiple source systems, daily and streaming inputs. BI users should not query Bronze for production KPIs.

What "good" looks like in the room

You open with a trust-failure story. You define each tier with grain and responsibilities. You draw the flow. You state access rules. You explain replay from Bronze. You name quality checks at boundaries. You discuss whether Silver is entity-current or immutable events. You keep Gold contracts stable.

Clarifying questions

  • Streaming into Bronze, batch dumps, or both?
  • Are Silver tables entity-current (SCD-ish) or immutable event facts?
  • Do data scientists get Silver access for exploration and training?
  • Tooling: Delta/Iceberg + dbt, or something else already standard here?
  • Which domains own which Gold marts?
  • What is the freshness SLA for Gold executive dashboards?

Scale and estimation prompts

Even without hyperscale numbers, show you think in volumes:

  • How many source systems and daily file volume?
  • Partition Bronze by ingest date for prune-friendly replay.
  • Estimate rebuild cost: reprocessing 30 days of Bronze into Silver when a dedupe key changes.
  • Concurrent BI queries should hit Gold, not scan raw JSON.

What is out of scope

  • Building a full data mesh org chart unless asked.
  • Vendor-only answers ("we use product X so medallion is done").
  • Letting every dashboard author define Gold metrics in a BI tool with no versioning.
  • Treating Bronze as a place for business cleanses that throw away evidence.

Expanded problem narrative

You are the first platform DE at a mid-size retailer. Sources include:

  • Orders OLTP database (nightly dump + CDC).
  • Clickstream Kafka topic.
  • SaaS marketing export (CSV daily).
  • Customer service tickets (API pull).

Executives want a single "trusted revenue" number. Data scientists want historical click features. Analysts want to explore quickly. If you give everyone Bronze access, you recreate the swamp. If you over-gate Silver so nobody can explore, teams build shadow pipelines in Sheets.

Your design must make the happy path obvious: producers land in Bronze, engineering publishes Silver with keys and types, analytics engineering publishes Gold marts with tests, BI reads Gold.

What the interviewer probes next

They will ask how you debug a wrong Gold metric upward. They will ask whether ML may read Silver. They will ask how you stop dashboards from scanning raw JSON. They will ask where masking applies. Have crisp answers ready.

Room diagram expectation

They expect something like:

Sources -> Bronze -> Silver -> Gold -> Consumers
              ^         |        |
              |         +--quarantine
              +--replay path when Silver changes

Talk while you draw. Silence with boxes is weaker than a spoken walkthrough of one order id.