What is Data Engineering System Design?

What is data engineering system design?

System design in data engineering goes beyond picking tools. It requires decomposing a business requirement — "real-time fraud detection" or "a 200-table analytics warehouse" — into a layered architecture where every component is chosen for explicit reasons, every tradeoff is documented, and every failure mode is addressed.

Senior and staff engineers distinguish themselves by how rigorously they make and communicate these decisions. A junior says "we need Kafka and Spark" without requirements analysis. A staff engineer starts with: 500K events/sec, p99 latency under 2 minutes, exactly-once guarantees, 3-year retention. Then they evaluate lambda vs kappa, document why Flink beats Spark Streaming for this SLO, address backfill and disaster recovery, and write an RFC with a risk register.

That depth of reasoning — not memorized vendor preferences — is what hiring committees and design reviews actually evaluate.

Why does system design matter?

• Promotion to senior+ at every top tech company is gated on system design depth, not tool recall
• A bad architecture decision at platform-build time costs the org years and tens of engineers
• RFCs and ADRs are how decisions outlive the engineer — without them every team relearns the same lessons
• Tradeoff matrices replace "what do you think?" debates with structured, scoreable engineering reasoning
• The same skill that wins interviews wins design reviews — and wins influence over org strategy
• Staff engineers spend more time on architecture and communication than on code

The six-layer architecture model

Every production data system can be decomposed into six layers. A complete design addresses all six — even when some are trivial for the specific problem.

1. Ingest — how data enters the system. Kafka or Kinesis for events, Debezium or Fivetran for CDC, REST or webhook for SaaS APIs. Define throughput, peak burst, and at-least-once vs exactly-once guarantees.
2. Store — where raw data lands. S3, GCS, or HDFS for lakes; Snowflake or BigQuery for warehouses. Choose by query patterns, cost-per-TB, and ecosystem fit.
3. Process — how data is transformed. Spark for large batch, Flink for streaming, dbt for SQL transformations in the warehouse. Decide based on volume, latency, and team SQL fluency.
4. Format — how files are organized on storage. Iceberg, Delta Lake, or Hudi give ACID transactions, schema evolution, and time travel on top of Parquet. Choose by feature support and ecosystem compatibility.
5. Serve — how consumers access data. Warehouse for BI, feature store for ML, REST or GraphQL APIs for product features, reverse ETL for SaaS sync.
6. Observe — how you monitor quality and SLOs. Lineage, freshness checks, anomaly detection, alerting, on-call runbooks.

Walk through every design — interview or production — by these six layers in order. Missing a layer is the most common reason a design review fails.

Lambda vs Kappa vs Medallion

Most teams in 2026 start with medallion on an Iceberg or Delta lakehouse and only escape into kappa when streaming latency requirements push them there. True lambda is rare in new builds — the operational tax of maintaining two pipelines rarely justifies the gain when modern streaming engines like Flink already provide correctness.

RFCs, ADRs, and tradeoff matrices

System design is half engineering, half writing. The artifacts that separate staff-level work from senior:

• RFC (Request for Comments) — a 3–6 page document submitted before building. Sections: context, requirements, constraints, alternatives considered, recommended design, risks, rollout plan. Reviewed by 3+ engineers including a principal.
• ADR (Architecture Decision Record) — a 1-page record stored in git alongside code. One per major decision (table format, processing engine, schema-evolution policy). Captures what was decided, why, and what was rejected.
• Tradeoff matrix — a scored grid: rows are options, columns are dimensions (latency, cost, ops, team fit, ecosystem). Cells contain numeric scores with one-line justifications. Forces the conversation onto explicit criteria instead of vendor preference.

A staff promo packet routinely includes 3–5 RFCs the candidate authored. The artifacts ARE the work.

Common mistakes (and what to do instead)

• Naming tools before naming requirements — "we need Kafka" without throughput, latency, retention, or consumer count is not a design. Always lead with the numbers.
• No alternatives considered — listing only the recommended design tells reviewers you didn't do the work. Show 2–3 alternatives with explicit reasons for rejection.
• Missing the observability layer — pipelines without freshness, lineage, and on-call runbooks are not production. The sixth layer is not optional.
• Designing for peak load, not steady state — costing infrastructure for the 99th-percentile burst is how budgets explode. Right-size for steady state with autoscaling for bursts.
• Treating cost as someone else's problem — finance now expects the designing engineer to model 1-year cost trajectory. Include a cost section in every RFC.
• Skipping the failure-mode walkthrough — for every component, write down what breaks first and how the system recovers. Reviewers will ask. Have the answer.

Who is system design for?

System design is for mid-to-senior data engineers preparing for senior or staff promotion, for platform engineers owning org-wide architecture decisions, and for any data engineer interviewing at a top tech company where the system design loop is the dominant signal.

Teams that benefit most:

• Senior data engineers eyeing a staff promo and looking for a portfolio of RFCs
• Platform leads architecting a new lakehouse, feature store, or streaming platform from scratch
• Engineers interviewing at FAANG / unicorn / quant where system design is half the loop
• Tech leads who keep losing design reviews to better-prepared peers and want a structured framework