Practice system design problems for data engineer roles differ from practice SQL or Python problems because there is no auto-grader for "is this architecture correct". Multiple valid designs exist for any scenario. The rubric scores the decision process and the failure-mode articulation, not a specific canonical answer.

Five scenario families anchor the practice catalog. Streaming ingestion: design a pipeline that ingests 10B clickstream events per day with a 15-minute dashboard freshness SLA, where the dashboard sits on top of a BI tool that cannot handle table swaps. Daily warehouse load: design a daily ETL from a 50TB Postgres production database to Snowflake with a 4-hour load window and full backfill capability. ML feature pipeline: design a feature store with online (10ms read latency) and offline (training-time joins) paths for a recommendation model, with feature parity between paths. Reconciliation pipeline: design a daily reconciliation between payment processor settlement reports and internal transaction events, with discrepancy alerting and idempotent re-runs. Multi-region warehouse: design a multi-region active-active warehouse for a global product with regional sovereignty requirements (EU data stays in EU).

Each problem ships with a rubric-scored verdict covering five dimensions. SLA match: does the proposed design meet the freshness, throughput, and latency requirements stated in the scenario. Cost reasoning: back-of-envelope numbers for Kafka shards, Spark workers, Snowflake credits, S3 storage class trade-offs. Failure modes: 3 per component, with detection mechanism and recovery strategy. Tool fit: why this technology (Kafka vs Kinesis vs Pub/Sub) and not the alternative, defended in one sentence. Adapt-on-fly: when the rubric flips a requirement (SLA tightens, volume jumps 100x, downstream constraint added), does the design modify in place or restart from scratch.

Common failure modes the rubric explicitly fails. Skipping clarifying questions (jumping straight to drawing without nailing down throughput, latency, durability requirements). Naming a tool without defending the choice ("I'd use Spark" without saying why over Flink or Dataflow). Missing failure modes (not naming what happens when Kafka brokers die, when Spark executors OOM, when Snowflake MERGE deadlocks). No cost reasoning at L5+ (a senior data engineer should produce rough numbers, not just architecture). Throwing out the design on a mid-round pivot instead of modifying in place.

The senior data engineer who has practiced 5 of these scenarios with rubric review usually arrives at the interview with the failure-mode taxonomy internalized. The most common positive signal is the candidate who names a failure mode the interviewer was about to ask about, before being asked. That moves the rubric from "could answer when prompted" to "anticipates the problem".

Pipeline Architecture (123)

• 45 Minutes Turned Into 3.5 Hours - medium - Spark jobs are running. Just not fast enough.
• 600 Million Events a Day - hard - 600 million events a day. Two years of retention.
• A Clean Number for Every Merchant - hard - Raw payment logs in. Clean merchant summaries out.
• A Million Cars Phoning Home - hard - Every vehicle is a sensor. Deploy the pipeline to catch it all.
• Analysts Are Slowing the Store Down - medium - Orders placed. Data warehouse hungry.
• A New Column on a Billion Rows - hard - Add and backfill a new column to a billion-row production table with zero downtime.
• A Shared Drive Full of Contracts - medium - Buried in PDFs. The data is in there somewhere.
• A Stream All Day and a File at Midnight - hard - Real-time and batch. Same pipeline. No compromises.
• Badging Items That Already Sold Out - hard - Same-day delivery. The features have to be faster.
• Basel, CCAR, and Monday Morning - medium - The regulator does not accept 'eventually consistent.'