DataEngPrep.tech
QuestionsPracticeAI CoachDashboardPacksBlog
ProLogin
Home/Questions/System Design/Architecture/Design a data model for capturing watch sessions across multiple devices

Design a data model for capturing watch sessions across multiple devices

System Design/Architecturehard4.1 min readPremium

**Section 1 — The Context (The 'Why')** This system faces scale and failure challenges at production. A naive approach breaks under load, loses data, or violates compliance. The primary challenge varies by domain: notifications need preference respect; banking needs ACID;...

🤖 Analyze Your Answer
Frequency
Low
Asked at 1 company
Category
179
questions in System Design/Architecture
Difficulty Split
15E|6M|158H
in this category
Total Bank
1,863
across 7 categories
Asked at these companies
Netflix
Key Concepts Tested
optimizationpartitionspark

Why This Question Matters

This hard-level System Design/Architecture question appears frequently in data engineering interviews at companies like Netflix. While less common, it tests deeper understanding that distinguishes strong candidates. Mastering the underlying concepts (optimization, partition, spark) 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
812 wordsIncludes code

Section 1 — The Context (The 'Why')
This system faces scale and failure challenges at production. A naive approach breaks under load, loses data, or violates compliance. The primary challenge varies by domain: notifications need preference respect; banking needs ACID; pipelines need idempotency. Failure modes include partition events, consumer lag, and poison messages.

Section 2 — The Diagram

[Player] --> [Kafka]
play|pause|seek
device_id | content
|
v
[Session] duration
Multi-device | user
|
v
[Reco] Churn|Engage

Section 3 — Component Logic

  • ASCII Architecture Diagram

  • [Player] --> [Kafka]
    play|pause|seek
    device_id | content
    |
    v
    [Session] duration
    Multi-device | user
    |
    v
    [Reco] Churn|Engage

  • CAP Theorem Trade-offs
  • Watch sessions: AP—events arrive out-of-order. Session boundaries use watermarks. Aggregate by user is eventually consistent.
  • Cost vs. Latency
  • MSK ($0.21/broker) for events. Flink EMR for session agg. Redis ($0.05/hr) for hot state. S3/Delta for cold. Netflix scale: billions events; partition by user_id. Churn ML: batch vs stream cost.
  • Blast Radius
  • Event lose: Session incomplete. Multi-device: Merge by user. Watermark: Late data handling.
  • Senior Terminology
  • Session: Watermark. Multi-device: user_id. Fan-out: Reco + analytics. TTL: Event retention. Each component has a distinct role: the ingestion layer buffers events and applies backpressure when consumers lag; the processing layer must implement idempotency via merge keys (pk, batch_id) to prevent duplicates on retry. Exactly-once semantics require a transactional producer plus idempotent sink—without both, at-least-once delivery doubles data. Data skew mitigation uses salting on high-cardinality keys and partitioning strategies that align with query filters. Fan-out patterns allow multiple consumers from the same source without data duplication. TTL policies on raw layers manage retention and cost. In production, we monitor consumer lag as a backpressure indicator, validate schema at ingest, and use a DLQ for poison messages. The diagram shows data flow left to right; partition count should equal or exceed consumer count for full utilization. For Kafka pipelines, RF=3 and min.insync.replicas=2 ensure no data loss on single broker failure. Checkpoint to durable storage (S3) not local disk. These choices—idempotency, checkpointing, replication factor—determine fault tolerance and data correctness.

    Section 4 — The Trade-offs (The 'Senior' part)
    CAP Theorem: We choose AP for streams and eventual-consistency layers; CP for ledger and warehouse where correctness matters. During partition, AP systems remain available; CP systems may reject writes.

    Cost vs. Performance: Glue $0.44/DPU-hr; MSK $0.21/broker-hr; S3 $0.023/GB; Kinesis $0.015/shard. Right-size: bursty jobs favor serverless; sustained favor EMR.

    Blast Radius: Primary component fail: downstream affected. Kafka broker: ISR election <10s. Spark: checkpoint replay. Sink: idempotent retry. DLQ isolates poison. Self-heal via replication and rebalance.

    Section 5 — Pro-Tip
    Pro-Move: user_id+device_id; session timeout; multi-device agg; churn features.
    Red Flag: Single device only 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 System Design/Architecture Questions

    hardWhat architecture are you following in your current project, and why?FreeeasyCDC During Migration - explain approaches for real-time Change Data CaptureFreehardBriefly explain the architecture of Kafka.FreehardDescribe the data pipeline architecture you've worked with.FreehardExplain the trade-offs between batch and real-time data processing. Provide examples of when each is appropriate.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 System Design/Architecture 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 System Design/Architecture questions →