Streaming and real-time ML quiz

Question 1

What is the fundamental difference between event time and processing time in stream processing?

Accepted Answer

Event time is when the event occurred at the source; processing time is when the stream engine processes it

Answer

Event time is set by the Kafka broker; processing time is set by the producer at message creation

Answer

Event time and processing time are identical when network latency is negligible

Answer

Processing time is always earlier than event time because brokers buffer messages

Question 2

In Apache Flink, what is a watermark and why is it essential for correct event-time windowing?

Accepted Answer

A watermark is a timestamp threshold signaling no earlier events are expected, enabling event-time window closure

Answer

A watermark is a checkpoint that saves operator state to durable storage on a cadence

Answer

A watermark marks the boundary between micro-batches in Spark Structured Streaming

Answer

A watermark is a rate limiter that prevents consumer lag accumulation in Kafka

Question 3

Which windowing strategy computes a 5-minute rolling average that updates every 30 seconds, and why?

Accepted Answer

Sliding window of 5-minute size with a 30-second hop interval

Answer

Tumbling window of 5 minutes, triggered every 30 seconds via a custom trigger

Answer

Session window with a 30-second inactivity gap and 5-minute maximum duration

Answer

Global window with a periodic trigger firing every 30 seconds and an evictor retaining 5 minutes

Question 4

What is the difference between exactly-once and at-least-once semantics in Kafka, and what trade-off do they impose on throughput and latency?

Accepted Answer

Exactly-once uses idempotent producers and Kafka transactions, trading latency and throughput for duplicate-free delivery

Answer

Exactly-once is achieved by setting acks=1 on the producer and retries=0 on the consumer

Answer

At-least-once can only be guaranteed with consumer group rebalancing disabled

Answer

Exactly-once and at-least-once are equivalent when auto.offset.reset=earliest is configured

Question 5

How does Kafka's consumer group mechanism enable horizontal scalability for stream consumers?

Accepted Answer

Each partition is consumed by exactly one consumer per group, so throughput scales linearly with partition count

Answer

All consumers in a group read all partitions simultaneously, enabling broadcast fan-out

Answer

Consumer groups enable multicast delivery where every group member receives every message

Answer

Kafka replicates messages across brokers so any consumer reads from the nearest replica for speed

Question 6

Describe the ADWIN concept drift detection algorithm and explain when you would prefer it over the Page-Hinkley test.

Accepted Answer

ADWIN uses adaptive variable-length windows comparing sub-window means; it is preferred when drift magnitude is unknown or variable

Answer

ADWIN uses a fixed window; Page-Hinkley uses a variable window that grows until drift is detected

Answer

Page-Hinkley is superior for abrupt concept drift because it resets its counter immediately on alarm

Answer

ADWIN is a supervised method requiring labeled examples at each step; Page-Hinkley is fully unsupervised

Question 7

In the River library for online learning, why must `predict_one` be called before `learn_one` in the evaluation loop?

Accepted Answer

predict_one before learn_one ensures evaluation happens before the label is seen, preventing data leakage

Answer

The order does not matter because River buffers gradient updates asynchronously across calls

Answer

learn_one must be called first to initialize model weights before predict_one can produce valid output

Answer

predict_one and learn_one are interchangeable; River handles ordering internally via a task queue

Question 8

What is the Lambda architecture, what problem does it solve, and what major criticism spawned the Kappa architecture?

Accepted Answer

Lambda's dual batch+speed layers create dual-codebase maintenance complexity; Kappa unifies both as a single streaming pipeline on a replayable log

Answer

Lambda was deprecated because streaming systems cannot correctly process historical data at scale

Answer

Lambda architecture is too slow for real-time; Kappa replaces it entirely with distributed batch processing

Answer

Kappa architecture adds a dedicated ML training layer on top of Lambda's batch and speed layers

Question 9

What is backpressure in a streaming system and how does Apache Flink handle it natively?

Accepted Answer

Flink uses credit-based flow control: upstream sends data only when downstream signals available buffer credit, propagating pressure to the source

Answer

Flink handles backpressure by dropping the slowest messages and emitting a backpressure metric alert

Answer

Flink pauses all source readers globally when any operator's queue exceeds 80% capacity

Answer

Backpressure in Flink triggers automatic partition rebalancing across Kafka consumer groups

Question 10

How does Spark Structured Streaming differ from legacy Spark Streaming (DStreams) in its execution model and API?

Accepted Answer

Structured Streaming models a stream as an unbounded DataFrame with a unified batch/stream API; DStreams use RDD micro-batches with a separate API

Answer

DStreams use DataFrames under the hood; Structured Streaming uses RDDs with a higher-level wrapper

Answer

Structured Streaming is fully event-driven per record; DStreams use a polling model from Kafka

Answer

Structured Streaming processes exactly one record per trigger; DStreams always batch exactly 1,000 records

Question 11

What is a feature store, and why is a point-in-time correct join critical when building a training dataset from streaming features?

Accepted Answer

Point-in-time correct joins ensure only features available before the label timestamp are used, preventing future feature leakage

Answer

Point-in-time correct joins prevent duplicate rows caused by Kafka topic reprocessing during training

Answer

Point-in-time correct joins are needed exclusively to handle late-arriving Kafka messages during batch training

Answer

Point-in-time correct joins are a Feast-specific query optimization with no conceptual relevance to other feature stores

Question 12

Explain the Hoeffding Tree (VFDT) algorithm and why it is architecturally well-suited for streaming classification.

Accepted Answer

Hoeffding Trees use the Hoeffding bound to make statistically valid split decisions from small samples, enabling bounded-memory incremental tree growth

Answer

Hoeffding Trees store all training data in a compressed B-tree, enabling O(1) lookups at the cost of high memory

Answer

Hoeffding Trees require periodic batch retraining triggered by a drift detection algorithm

Answer

Hoeffding Trees are limited to binary classification and cannot handle multi-class streaming tasks

Question 13

What is Change Data Capture (CDC) and how is it used to feed real-time ML feature pipelines?

Accepted Answer

CDC reads the database transaction log to capture row-level changes, publishing them to a message broker for downstream real-time consumption

Answer

CDC periodically runs full table scans and diffs the results against the previous scan to detect changes

Answer

CDC requires a separate read replica and compares row checksums every minute to detect mutations

Answer

CDC is a Kafka-native feature that monitors consumer lag to infer which database rows have changed

Question 14

How would you implement a stateful streaming feature that counts user transactions in the last 10 minutes without re-reading historical events?

Accepted Answer

Maintain a stateful time-ordered deque per user key, appending new events and evicting entries older than 10 minutes on each update

Answer

Store all transactions in a remote database and run a COUNT query with a WHERE clause on every new event

Answer

Use a tumbling window that resets every 10 minutes and emits the final count at window close

Answer

Use Kafka log compaction to retain only the latest transaction per user key and count retained records

Question 15

What role does the learning rate play in online SGD, and which adaptive optimizer family is most commonly applied to streaming feature data with sparse, high-cardinality features?

Accepted Answer

Adaptive optimizers like Adagrad/Adam scale per-parameter learning rates based on gradient history, benefiting sparse high-cardinality streaming features

Answer

A fixed high learning rate is preferred in streaming ML to ensure fast adaptation regardless of feature frequency

Answer

The learning rate has no practical effect when processing one sample at a time as in online SGD

Answer

Online SGD always uses a learning rate of 1/n (where n is samples seen) regardless of feature type

Question 16

How does Flink's TwoPhaseCommitSinkFunction achieve exactly-once output semantics when writing to an external transactional system like Kafka?

Accepted Answer

Flink's TwoPhaseCommitSinkFunction pre-commits on checkpoint barrier and commits only after full checkpoint success, aborting on failure for replay

Answer

Flink achieves exactly-once by deduplicating sink writes using a bloom filter keyed on message hash

Answer

Flink appends a UUID to each record and the sink deduplicates on insert to guarantee idempotency

Answer

Exactly-once in Flink only works with HDFS/S3 sinks; Kafka sinks are inherently at-least-once

Question 17

What is the purpose of a schema registry (e.g., Confluent Schema Registry) in a Kafka-based real-time ML pipeline?

Accepted Answer

Schema registry stores and enforces data schemas per topic, preventing serialization mismatches and enabling safe schema evolution without downtime

Answer

Schema registry acts as a Kafka broker plugin that compresses topic messages to reduce network bandwidth

Answer

Schema registry provides per-producer authentication tokens and manages access control lists for topics

Answer

Schema registry is only required for JSON topics; Avro topics embed their schemas inline and need no registry

Question 18

What is ONNX Runtime and why is it commonly used for low-latency model serving in real-time ML systems?

Accepted Answer

ONNX Runtime is an inference engine for ONNX-format models that applies graph optimizations and hardware-specific execution providers to reduce serving latency

Answer

ONNX Runtime is a Kubernetes operator that schedules and scales model replicas for load balancing

Answer

ONNX Runtime serializes Flink/Kafka consumer offsets alongside model checkpoints for exactly-once inference

Answer

ONNX Runtime is a model versioning and experiment tracking tool similar to MLflow but optimized for artifact storage speed

Question 19

What is the key difference between a stream-table join and a stream-stream join in Apache Flink or Kafka Streams?

Accepted Answer

Stream-table joins enrich stream events with the current table value (non-windowed); stream-stream joins match events from two streams within a time window

Answer

Stream-table joins require two watermarks to close; stream-stream joins require no watermarks because the table is static

Answer

Stream-table joins are only supported in Kafka Streams, not in Apache Flink SQL

Answer

Stream-stream joins are always more efficient because they avoid the overhead of maintaining a local state store

Question 20

How does the precision-recall evaluation trade-off change when transitioning a fraud detection model from offline testing to real-time production?

Accepted Answer

Online fraud evaluation must account for distribution shift and delayed label feedback, making offline PR curves unreliable proxies for production performance

Answer

The PR trade-off is identical online and offline if the offline test set is drawn from the same time period as production traffic

Answer

Real-time evaluation requires no threshold tuning because streaming engines auto-calibrate model probabilities to the live distribution

Answer

Precision-Recall is irrelevant for production fraud systems; only AUC-ROC and KS-statistic matter operationally

Question 21

What is the core trade-off between micro-batch and true record-at-a-time (continuous) streaming execution, and how does it influence system design choices?

Accepted Answer

Micro-batch favors throughput with tunable batch intervals; true streaming minimizes latency at higher per-record overhead — choice depends on the latency SLA

Answer

Micro-batch always achieves lower latency than true streaming because it batches network calls and reduces round trips

Answer

True streaming requires watermarks for all use cases; micro-batch does not support event-time semantics

Answer

Micro-batch and true streaming produce identical results only when exactly-once delivery semantics are enabled end-to-end

Question 22

What distinguishes prequential (test-then-train) evaluation from holdout evaluation for assessing online learning models on streams?

Accepted Answer

Holdout evaluation is unbiased only for stationary distributions; prequential tests before training on each example and works correctly for non-stationary streams

Answer

Prequential evaluation requires true labels to be available one full day after prediction; holdout does not impose this delay

Answer

Prequential evaluation is equivalent to k-fold cross-validation adapted to streaming data

Answer

Holdout evaluation is always preferred in production because prequential wastes too many labeled examples on evaluation

Question 23

How does Flink's RocksDB state backend differ from the heap-based state backend, and when should each be chosen for a streaming ML feature computation job?

Accepted Answer

Heap state is fastest but RAM-bounded; RocksDB stores state on local disk enabling larger state at the cost of serialization overhead and higher read latency

Answer

RocksDB state is stored in HDFS and requires a YARN cluster; heap state is only for local development mode

Answer

Heap state supports only primitive Java types; RocksDB is required for any complex types like maps or lists

Answer

RocksDB state is automatically replicated across Flink TaskManagers; heap state has no fault tolerance

Question 24

How does the CUSUM (Cumulative Sum) control chart function as a concept drift detector in a streaming ML pipeline?

Accepted Answer

CUSUM tracks the cumulative sum of deviations from a reference statistic and alarms when it exceeds a threshold, detecting small persistent shifts in model error

Answer

CUSUM detects abrupt concept drift by comparing the current batch error rate directly to the previous batch's error rate

Answer

CUSUM is a windowed averaging method that resets its accumulator every N samples to detect recurring seasonal drift

Answer

CUSUM requires ground-truth labels at every time step and cannot be applied to unsupervised monitoring statistics

Question 25

What is a Kafka 'tombstone' message and why is it important for GDPR compliance in stateful streaming ML applications?

Accepted Answer

A tombstone is a null-value message for a key that triggers deletion from log-compacted topics and downstream state stores, enabling compliant data removal

Answer

A tombstone is a special broker-level marker that pauses replication for a topic partition during maintenance

Answer

A tombstone is a Kafka producer acknowledgment record confirming a message reached all in-sync replicas

Answer

A tombstone is a schema-registry entry that marks a schema version as deprecated and prevents new producers from using it

Question 26

How would you architect a real-time personalized recommendation system serving item embeddings with under 10ms p99 latency at 100,000 RPS?

Accepted Answer

Pre-compute embeddings offline, store in a low-latency HNSW vector store, and serve via ANN search at inference time to meet sub-10ms p99

Answer

Run a full two-tower neural model on every request computing fresh user and item embeddings dynamically from raw features

Answer

Use SQL JOINs against a Postgres table of precomputed affinity scores, relying on connection pooling to meet the 10ms budget

Answer

Stream all user interactions through Spark Structured Streaming to generate and cache recommendations on a 30-second micro-batch cadence

Question 27

What is Kafka Streams' local state store and how does it differ from using a shared remote database for streaming aggregations?

Accepted Answer

Local state stores keep aggregation state in-process, eliminating network round-trips versus a remote database, at the cost of partition-bound access patterns

Answer

Kafka Streams local state stores are write-only during processing; reads must always go directly to the underlying Kafka topic

Answer

Remote databases are always preferred over local state stores because they provide ACID transactions that Kafka Streams cannot guarantee

Answer

Local state stores in Kafka Streams are purely ephemeral and are not snapshotted to Kafka, so they are lost on any task restart

Question 28

What is the cold start problem in streaming ML, and what are the most effective mitigation strategies that avoid requiring historical data?

Accepted Answer

Cold start can be mitigated via population priors, content-based features, contextual bandits, or meta-learning — treating it as exploration rather than prediction

Answer

Cold start is only a problem in collaborative filtering models; content-based models have no cold start because they use item attributes

Answer

Cold start is eliminated by increasing the model's training window to include all historical interactions regardless of entity age

Answer

Streaming models inherently solve cold start because they continuously learn from new data after the first few interactions in the same session

Question 29

What three mechanisms does Apache Flink provide for handling late-arriving data, and when should each be used?

Accepted Answer

Flink handles late data via allowed lateness (window extension), side outputs (separate late stream), or discard, depending on accuracy and SLA requirements

Answer

Flink always discards late events; the programmer must resend them via a separate producer if re-processing is needed

Answer

Late events in Flink can only be handled by globally increasing the watermark delay for the entire job

Answer

Late data is impossible in Flink because watermarks guarantee strict event-time ordering at every operator boundary

Question 30

What is the dual write problem in real-time ML feature pipelines and how does the outbox pattern resolve it?

Accepted Answer

The outbox pattern writes events into the same DB transaction as the state change, then uses CDC to reliably publish to Kafka, eliminating DB-broker inconsistency

Answer

The dual write problem is solved by writing to Kafka first and using a Kafka consumer to update the database in a separate transaction

Answer

Dual writes are fully prevented by using Kafka's transactional producer API directly in the application service layer

Answer

The dual write problem only affects NoSQL databases; relational databases with WAL-based replication are inherently immune

Test yourself