Dataford
Interview QuestionsInterview GuidesExperiencesCoaching
New
Pricing
Get started
Dataford
Popular roles
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Browse
Browse All RolesEvery role hub, from analyst to MLBrowse All CompaniesCompany-specific interview loopsAll Interview GuidesThe full guide library
Top questions by role
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Top questions by skill
SQLPythonStatisticsMachine LearningA/B TestingSystem DesignGenerative AIProduct SenseMetricsBehavioral
Browse all questions →Try a mock interview
Experiences
Practice
Mock InterviewsTimed interview simulations with feedbackCoaching1:1 coaching with people at your target companiesSuccess PathYour 6-week structured planModulesCurated lessons by topicWebinarsTalks from ex-Big Tech data leadsPlaygroundA free-form scratch editor
Learn
BlogInterview strategy and career adviceTech Job Market ReportHiring trends across data and AI rolesFor UniversitiesDataford for career centersAbout DatafordWho we are and how we build
Pricing
Build my plan

Handle Late Data in Streams

EasyPipelines00:00
Practice interviewer
In session
5 left
00:00

Your question is Handle Late Data in Streams. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

Context

Meta’s analytics platform ingests client and server events from Facebook and Instagram surfaces into a near-real-time pipeline used for product dashboards and experiment reads. The current stream path publishes fast aggregates, but mobile offline behavior, network retries, and regional outages cause events to arrive minutes or hours late, leading to undercounted metrics and inconsistent downstream tables.

You are asked to design a late-data handling strategy for a streaming pipeline built on Apache Kafka, Apache Flink, HDFS, and Presto, orchestrated by Apache Airflow, while fitting into Meta-style warehouse patterns and operational expectations.

Scale Requirements

  • Ingress: 2.5M events/sec peak, 800K avg
  • Event size: 1.2 KB average Avro payload
  • Daily volume: ~200B events/day, ~240 TB raw/day
  • Freshness target: P95 event-to-queryable latency under 3 minutes
  • Late data profile: 92% within 5 minutes, 7% within 2 hours, 1% up to 7 days late
  • Retention: 30 days raw stream replay, 180 days curated warehouse tables

Requirements

  1. Design event-time processing with watermarks to produce correct windowed aggregates despite late arrivals.
  2. Support upserts/retractions so downstream fact tables and metric tables can be corrected when late events arrive.
  3. Ensure idempotent handling of duplicates caused by client retries and producer replays.
  4. Route events arriving beyond the allowed lateness threshold into a backfill path and describe how they are merged.
  5. Define monitoring for lateness distribution, watermark lag, state growth, and data quality regressions.
  6. Explain how batch backfills and stream processing remain consistent for the same business logic.

Constraints

  • Do not increase median query latency for dashboards beyond current SLA.
  • Stateful operators must remain bounded and recoverable during regional failover.
  • Assume schema evolution is frequent across mobile clients.
  • Cost increase should stay under 20% versus the current streaming footprint.