DataEngPrep.tech
QuestionsPracticeAI CoachDashboardPacksBlog
ProLogin
Home/Questions/Spark/Big Data/Design an ETL pipeline using Kafka and Spark Streaming

Design an ETL pipeline using Kafka and Spark Streaming

Spark/Big Datahard3.7 min readPremium

**Section 1 — The Context (The 'Why')** ETL pipelines combining Kafka and Spark Streaming must reconcile batch-oriented processing with continuous ingestion. The primary challenge: offset management—without checkpoints, a Spark job restart replays from the beginning or skips...

🤖 Analyze Your Answer
Frequency
Low
Asked at 1 company
Category
452
questions in Spark/Big Data
Difficulty Split
88E|81M|283H
in this category
Total Bank
1,863
across 7 categories
Asked at these companies
Meesho
Key Concepts Tested
etloptimizationpartitionspark

Why This Question Matters

This hard-level Spark/Big Data question appears frequently in data engineering interviews at companies like Meesho. While less common, it tests deeper understanding that distinguishes strong candidates. Mastering the underlying concepts (etl, optimization, partition) will help you answer variations of this question confidently.

How to Approach This

This is a senior-level question that tests architectural thinking. Lead with the high-level design, then drill into specifics. Discuss trade-offs explicitly - there is rarely one correct answer. Show awareness of scale, fault tolerance, and operational complexity. The expert answer includes a code example that demonstrates the implementation pattern.

Expert Answer
740 wordsIncludes code

Section 1 — The Context (The 'Why')
ETL pipelines combining Kafka and Spark Streaming must reconcile batch-oriented processing with continuous ingestion. The primary challenge: offset management—without checkpoints, a Spark job restart replays from the beginning or skips data. Another failure mode is duplicate writes from at-least-once delivery when the sink is not idempotent. A naive approach processes without bookmarks or merge keys, causing repeated inserts and incorrect aggregates.

Section 2 — The Diagram

[Kafka Topics] --> [Consumer Group]
|
v
[Spark Structured Streaming]
Micro-batch | Trigger
|
v
[Delta Bronze] --> [Silver]
|
v
[Gold Marts] --> [dbt / BI]

Section 3 — Component Logic
Kafka Topics with partitions keyed by entity ID ensure that related events land in the same partition for ordering. The Consumer Group coordinates offset commits—each partition is consumed by exactly one consumer in the group. Spark Structured Streaming runs micro-batches (e.g., 1–5 min triggers); we use it over DStreams because Structured Streaming supports event-time, watermarking, and exactly-once with checkpoint + idempotent sink. The Delta Bronze layer appends raw data; Silver applies MERGE on (pk, batch_id) for idempotency—reprocessing a batch produces identical results. Gold marts are aggregated tables for BI. Fan-out patterns allow multiple consumers (stream + batch) from the same Kafka topic. Bookmarks in Glue or checkpoint paths in Spark enable incremental processing without full replay.

Section 4 — The Trade-offs (The 'Senior' part)
CAP Theorem: We choose AP—Kafka provides high availability; consumers tolerate eventual consistency during rebalances. Delta Lake merge provides idempotent consistency at the sink. For analytics, Silver and Gold stale by 5–10 minutes is acceptable.

Cost vs. Performance: Glue ($0.44/DPU-hr, 10 min minimum) vs EMR Serverless ($0.06/vCPU-hr): Glue is simpler for Kafka-to-Delta. MSK ($0.21/broker-hr). Delta storage: $0.023/GB on S3. EMR wins for 8hr+ daily jobs.

Blast Radius: Kafka broker fail: ISR replica becomes leader in under 10 seconds. Spark executor fail: tasks retry on another executor; checkpoint restores. Driver fail: job dies—restart from checkpoint. Delta merge is idempotent, so retries are safe.

Section 5 — Pro-Tip
Pro-Move: Checkpoint to S3; MERGE by (pk, batch_id); 5-min micro-batches; use Glue bookmarks for incremental file processing.
Red Flag: No checkpoint—offset loss on restart causes full replay or data loss; interviewers expect checkpoint strategy. From a Principal Engineer perspective, the key differentiators are operational rigor—defined SLAs, runbooks, and chaos testing—and cost consciousness—right-sizing, reserved capacity, and incremental processing to minimize compute. The failure modes we guard against include partition events (Kafka ISR, consumer rebalance), poison messages (DLQ with alerting), and offset loss (S3 checkpoint). Interview red flags include missing idempotency (duplicates on retry), no DLQ (one bad record blocks the pipeline), and checkpointing to ephemeral storage (state lost on preemption). Production systems require monitoring of consumer lag, data freshness SLOs, and cost per record processed. Schema evolution should be additive-only with Schema Registry; partitioning strategies must align with query filters (date, region); blast radius is contained through replication, circuit breakers, and graceful degradation. When choosing between CP and AP: ledger and warehouse layers favor consistency; streams and caches favor availability. Cost optimization: Glue for bursty jobs under 2 hours; EMR for sustained 8+ hour workloads. Always quantify improvements—latency reduction, cost savings, volume handled. Data skew mitigation via salting and AQE prevents hotspot tasks; exactly-once semantics require idempotent sinks; fan-out patterns enable multiple consumers without duplication. TTL policies on Bronze reduce storage cost; incremental processing cuts compute by 90% versus full scans. Replication factor of three with min.insync.replicas=2 ensures durability; consumer count should match or exceed partition count; event-time over processing-time handles late arrivals correctly. Medallion architecture separates raw from curated; quality gates at Silver prevent bad data propagation; conformed dimensions enable cross-mart consistency. In interviews, demonstrate production experience by citing specific metrics: P95 latency, cost per million events, recovery time objective. Avoid generic answers; tie each design choice to a measurable outcome. The trade-off between consistency and availability is per-component: choose CP for financial transactions, AP for analytics. Scale testing should cover 10x peak load; runbooks should document failure recovery steps. Blue-green deployments enable zero-downtime schema evolution; view abstraction with COALESCE supports additive column migration. For real-time systems, define SLOs before building—lag under five minutes and freshness under one hour are common targets. Correlation IDs in log records enable end-to-end tracing when debugging production incidents. Reserve capacity for traffic spikes; implement circuit breakers to prevent cascading failures across dependent services. Document design decisions and their trade-offs for future maintainability. This demonstrates production-grade system design thinking.

This answer is partially locked

Unlock the full expert answer with code examples and trade-offs

Recommended

Start AI Mock Interview

Practice real interviews with AI feedback, track progress, and get interview-ready faster.

  • Unlimited AI mock interviews
  • Instant feedback & scoring
  • Full answers to 1,800+ questions
  • Resume analyzer & SQL playground
Create Free Account

Pro starts at $24/mo - cancel anytime

Just need answers for quick revision?

Download curated PDF interview packs

Interview Packs
1,800+ real interview questions sourced from 5 top companies
AmazonGoogleDatabricksSnowflakeMeta
This answer is in the DE Mastery Vault 2026
1,863 questions with expert answers across 7 categories →

Free: Top 20 SQL Interview Questions (PDF)

Get the most asked SQL questions with expert answers. Instant download.

No spam. Unsubscribe anytime.

Related Spark/Big Data Questions

mediumWhat is the difference between repartition and coalesce in Apache Spark?FreehardWhat is the difference between SparkSession and SparkContext in Spark?FreemediumWhat is the difference between cache() and persist() in Spark? When would you use each?FreemediumWhat is the difference between groupByKey and reduceByKey in Spark?FreemediumWhat is the difference between narrow and wide transformations in Apache Spark? Explain with examples.Free

Want to know if YOUR answer is good enough?

Paste your answer and get instant AI feedback with a FAANG-level improved version.

Analyze My Answer — Free

According to DataEngPrep.tech, this is one of the most frequently asked Spark/Big Data interview questions, reported at 1 company. DataEngPrep.tech maintains a curated database of 1,863+ real data engineering interview questions across 7 categories, verified by industry professionals.

← Back to all questionsMore Spark/Big Data questions →