Top 30 Streaming Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   Why should batch product metadata and streaming click events typically use different physical storage formats?

   • aColumnar formats should be used for both to maximize compression and query performance across all workloads
   • bThe choice is purely based on cost, so the cheapest format should be selected regardless of data velocity or access pattern
   • cRow-oriented formats minimize write overhead for high-velocity events, while columnar formats improve projection and compression for batch analytics
   • dRow-oriented formats are preferred for both because they simplify schema evolution and reduce system complexity
   Show the answer

   Answer: c · Row-oriented formats minimize write overhead for high-velocity events, while columnar formats improve projection and compression for batch analytics

   Row-oriented formats minimize write overhead for streaming ingestion while columnar formats allow efficient projection and compression for batch training data. Choosing columnar for both is tempting but adds unnecessary write overhead to high-velocity events.

   Read the full bite: Design ingestion for clickstream and batch product metadata

2. Question 2 of 30

   Which approach correctly balances completeness and resource limits when handling late events in an event-time streaming pipeline?

   • aUse event-time windows with watermarks, an allowed lateness bound, and idempotent sink updates
   • bRetain all window state indefinitely and use framework checkpointing for exactly-once guarantees
   • cBuffer out-of-order events in memory for a fixed duration without explicit watermark semantics
   • dRely on processing-time windowing with extended micro-batch intervals to cover expected delays
   Show the answer

   Answer: a · Use event-time windows with watermarks, an allowed lateness bound, and idempotent sink updates

   Event-time windows with watermarks and allowed lateness explicitly bound how long state is retained for late data, while idempotent sinks ensure reprocessing does not double count. Retaining all window state indefinitely avoids data loss but causes unbounded memory growth and garbage collection issues, and framework checkpointing alone does not guarantee end-to-end sink correctness.

   Read the full bite: How would you handle late-arriving data in a streaming analytics pipeline?

3. Question 3 of 30

   A streaming pipeline needs to calculate aggregates based on when events actually happened, even if they arrive late. Which set of features is essential for achieving this correctness?

   • aBatch processing for all late data, fixed-size buffers, and periodic state checkpoints.
   • bDropping any data that arrives after its window's initial close, using wall-clock time for windowing.
   • cProcessing-time windowing, system clock timers, immediate output, and dead-letter queues.
   • dEvent-time windowing, data-driven watermarks, allowed lateness, and triggers.
   Show the answer

   Answer: d · Event-time windowing, data-driven watermarks, allowed lateness, and triggers.

   To ensure correctness with late-arriving data, streaming pipelines rely on event-time windowing, watermarks to signal data completeness, allowed lateness to keep windows open, and triggers to emit corrected results. Processing-time windowing or dropping late data would lead to incorrect analytics.

   Read the full bite: How do you handle late-arriving data in a streaming pipeline?

4. Question 4 of 30

   In a streaming pipeline calculating minute-by-minute analytics, how can you ensure events arriving late are correctly included in their original minute's aggregation?

   • aIncrease the buffer size on the ingestion topic to hold data longer before it enters the processing pipeline.
   • bRun a periodic batch job to reprocess the raw data, correcting any inaccuracies from the stream.
   • cAggregate events based on processing time, as it reflects when the system actually saw the data.
   • dDefine windows based on event time and use watermarks with an 'allowed lateness' to update aggregates as late data arrives.
   Show the answer

   Answer: d · Define windows based on event time and use watermarks with an 'allowed lateness' to update aggregates as late data arrives.

   The correct approach uses event-time windowing with watermarks to track progress and an 'allowed lateness' period to keep windows open for late arrivals. Relying on batch reprocessing (B) negates the low-latency benefits of streaming.

   Read the full bite: Handling Late-Arriving Data in a Streaming Pipeline

5. Question 5 of 30

   During a viral traffic spike, how should the pipeline protect ClickHouse from overload while keeping latency under 30 seconds?

   • aAbsorb the burst in Kafka partitions and apply backpressure upstream through Flink
   • bSwitch from streaming to hourly batch loads until traffic normalizes
   • cDrop excess events at the API gateway to prevent ingestion backlog
   • dImmediately auto-scale ClickHouse shards to handle the full 10x write volume
   Show the answer

   Answer: a · Absorb the burst in Kafka partitions and apply backpressure upstream through Flink

   Kafka serves as a durable retention buffer that absorbs traffic spikes and applies backpressure upstream, shielding ClickHouse from write overload while preserving the sub-30s latency budget. Distractor C is tempting but wrong because relying solely on instantaneous OLAP auto-scaling is operationally unrealistic and contradicts the architecture's explicit use of Kafka to decouple ingestion from querying.

   Read the full bite: Design a near real-time user interaction tracking and analytics system

6. Question 6 of 30

   Why is for await...of preferable to Promise.all for processing a multi-gigabyte file line by line?

   • aPromise.all cannot work with file streams at all
   • bIt automatically caches every line for reuse
   • cIt consumes lines lazily one at a time, keeping memory bounded with backpressure
   • dIt processes all lines in parallel for maximum speed
   Show the answer

   Answer: c · It consumes lines lazily one at a time, keeping memory bounded with backpressure

   for await...of awaits each item before requesting the next, so only one line is held at a time and memory stays flat. Promise.all would require buffering every line in memory at once.

   Read the full bite: Async iterators and for await...of for streaming

7. Question 7 of 30

   When aggregating a 50GB CSV on a 16GB machine, which strategy keeps peak memory usage proportional to a small fragment rather than the entire file?

   • aUse read_csv with usecols and dtype downcasting, then load everything into one DataFrame
   • bSample 1000 rows with nrows to inspect dtypes, then process the full file with default parameters
   • cIterate with read_csv(chunksize=...), aggregating each fragment and discarding it before reading the next
   • dLoad the full file with optimized dtypes but rely on OS swap for overflow
   Show the answer

   Answer: c · Iterate with read_csv(chunksize=...), aggregating each fragment and discarding it before reading the next

   Streaming with chunksize processes only one fragment at a time, keeping memory bounded by that fragment instead of the full 50GB. Option A is tempting because filtering columns and downcasting dtypes are valid optimizations, but materializing the entire file in a single DataFrame still exhausts RAM.

   Read the full bite: Process a 50GB CSV with only 16GB RAM

8. Question 8 of 30

   An analytics pipeline shows inflated daily user counts. To ensure data is clean before being queried, what is the most robust solution for handling potential duplicate events?

   • aAssign a unique ID to each event at the source and use a stateful stream processor to discard any ID already seen within a time window.
   • bRun a nightly batch job that scans the raw data, groups by event properties to find duplicates, and writes a new, cleaned table.
   • cAdd a database constraint on the user_id and timestamp columns to reject duplicate records upon insertion.
   • dStore all events, including duplicates, and have analysts use COUNT(DISTINCT event_id) in their queries.
   Show the answer

   Answer: a · Assign a unique ID to each event at the source and use a stateful stream processor to discard any ID already seen within a time window.

   The correct approach is to use a stateful stream processor to deduplicate events as they are ingested. This cleans the data before it's stored, ensuring accuracy and simplifying downstream queries. Using COUNT(DISTINCT) is a valid alternative but it pushes the deduplication logic to query-time, which can be less efficient and doesn't clean the underlying dataset.

   Read the full bite: How do you handle duplicate events in an analytics pipeline?

9. Question 9 of 30

   Which approach correctly prevents duplicate login events from inflating daily active user counts in a pipeline with at-least-once delivery?

   • aProcess daily batches once per day and assume late-arriving duplicates never cross partition boundaries
   • bSwitch the streaming platform to exactly-once delivery and use COUNT(*) on the raw stream
   • cRun SELECT DISTINCT * on the raw table before counting to remove duplicate rows
   • dMerge events using a unique event ID as the key and query with COUNT(DISTINCT event_id)
   Show the answer

   Answer: d · Merge events using a unique event ID as the key and query with COUNT(DISTINCT event_id)

   The correct answer builds an idempotent reporting layer: merging on a stable event ID prevents storage-level duplicates, while COUNT(DISTINCT event_id) collapses any remaining duplicates at query time. Option C is wrong because duplicate rows often differ in ingestion metadata like arrival time, so SELECT DISTINCT * will not treat them as duplicates.

   Read the full bite: How do duplicate events bias COUNT(*) and daily login reports?

10. Question 10 of 30

    Which design decision most directly prevents a surge from thousands of IoT devices from overwhelming downstream stream processors?

    • aIncreasing topic partition count to match the number of connected devices
    • bWriting raw telemetry directly to cold storage instead of the streaming buffer
    • cConfiguring Kafka with three replicas per partition and producer acks set to all
    • dPlacing local rate limiting and batching at the edge gateway before the Kafka backplane
    Show the answer

    Answer: d · Placing local rate limiting and batching at the edge gateway before the Kafka backplane

    The edge gateway isolates the core pipeline by applying local rate limiting and batching before Kafka. While three replicas with acks=all ensures durability against rack failures, it does not throttle an incoming flood from thousands of devices.

    Read the full bite: Design a scalable, fault-tolerant real-time IoT data ingestion system

11. Question 11 of 30

    Which statement best describes the core function of streaming ingestion in a real-time data architecture?

    • aIt ensures data is reliably captured from sources and delivered to stream storage for subsequent processing.
    • bIt orchestrates the entire end-to-end flow, from data capture to final data visualization.
    • cIt transforms raw event data into a standardized format before it reaches any storage layer.
    • dIt performs real-time analytics on incoming data streams to derive immediate insights.
    Show the answer

    Answer: a · It ensures data is reliably captured from sources and delivered to stream storage for subsequent processing.

    Streaming ingestion's primary role is to reliably capture data from various sources and deliver it to stream storage, acting as the 'loading dock' for the data pipeline. It is distinct from stream processing, which is responsible for analyzing or transforming the data.

    Read the full bite: Streaming Ingestion: Catching Data as It Happens

12. Question 12 of 30

    Which pairing best illustrates when streaming is genuinely justified over batch, alongside a critical infrastructure challenge that arises specifically in streaming?

    • aMonthly financial reporting; handling duplicate data during ingestion
    • bReal-time ad bidding; scheduling nightly downtime for operational maintenance
    • cFraud detection during payment authorization; managing backpressure during traffic spikes
    • dEnd-of-day inventory reconciliation; checkpointing stateful operations for recovery
    Show the answer

    Answer: c · Fraud detection during payment authorization; managing backpressure during traffic spikes

    Fraud detection requires sub-minute reaction time that batch cannot provide, and backpressure is a core operational challenge specific to streaming. Distractor D correctly identifies a low-latency use case but incorrectly assumes streaming pipelines have nightly downtime windows, whereas they actually impose a 24/7 operational burden with no batch-style maintenance window.

    Read the full bite: When is streaming better than batch, and what are its infrastructure challenges?

13. Question 13 of 30

    Which combination correctly implements memory-efficient, line-by-line streaming for a multi-gigabyte file in Go and Rust?

    • aGo: os.ReadFile then split by newlines; Rust: File::open and call read_line directly without BufReader
    • bGo: bufio.Scanner with ScanLines, checking scanner.Err() after the loop; Rust: BufReader with read_line into a reused String buffer
    • cGo: bufio.Scanner with ScanLines, skipping scanner.Err(); Rust: BufReader.lines() collected into a Vec<String>
    • dGo: bufio.NewReader with ReadString by newline; Rust: fs::read_to_string then split lines
    Show the answer

    Answer: b · Go: bufio.Scanner with ScanLines, checking scanner.Err() after the loop; Rust: BufReader with read_line into a reused String buffer

    Go's bufio.Scanner streams lines with a hidden buffer but requires an explicit scanner.Err() check after the loop, while Rust's BufReader paired with read_line and a reused String avoids per-line allocations. Distractor D is tempting because it names the right types, yet skipping scanner.Err() misses I/O errors and collecting lines into a Vec<String> loads the entire file into RAM, defeating streaming.

    Read the full bite: Compare efficient line-by-line file reading in Go and Rust

14. Question 14 of 30

    When should the on-call team be paged for a sudden add-to-cart drop?

    • aWhenever an operator marks a pattern as anomalous in the feedback dashboard
    • bAs soon as a single window shows a 50% drop from the previous hour's average
    • cOnly after a statistically significant deviation persists across multiple consecutive windows compared with a baseline tuned to the same hour and day of week
    • dOnce daily batch aggregates show a significant deviation from the prior day's totals
    Show the answer

    Answer: c · Only after a statistically significant deviation persists across multiple consecutive windows compared with a baseline tuned to the same hour and day of week

    The card specifies that alerts should fire only when a deviation persists across multiple consecutive windows against an adaptive baseline that learns from the same hour and day of week. Option B is tempting because a sharp single-window drop feels urgent, but it ignores daily cyclicality and causes false positives.

    Read the full bite: Design a system to detect sudden add-to-cart drops in real time

15. Question 15 of 30

    To keep all events for a given user ordered in a high-throughput stream while still scaling, what is the right approach?

    • aUse one global FIFO queue for strict total ordering
    • bInvoke a separate function per event with no batching
    • cDisable checkpointing to process faster
    • dPartition the stream by user ID so each user's events stay on one ordered shard
    Show the answer

    Answer: d · Partition the stream by user ID so each user's events stay on one ordered shard

    Partitioning by user ID keeps each user's events on one shard where order is preserved, while many shards scale throughput. A global FIFO serializes everything and cannot scale; per-event invocation and no checkpointing hurt cost and reliability.

    Read the full bite: High-throughput serverless stream processing

16. Question 16 of 30

    Which statement accurately describes how loading.js and error.js integrate with React primitives in the App Router?

    • aloading.js blocks navigation until the segment's async work resolves, and error.js catches runtime errors in both server and client components below it
    • bloading.js wraps its segment in a React Suspense boundary, and error.js adds a client-side Error Boundary for child segments
    • cloading.js provides instant feedback only during client-side navigation, and error.js catches rendering errors on the server during SSR
    • dThey eliminate the need for manual error handling in data fetching libraries and manual Suspense components inside page code
    Show the answer

    Answer: b · loading.js wraps its segment in a React Suspense boundary, and error.js adds a client-side Error Boundary for child segments

    loading.js is a convention that automatically wraps its segment in a React Suspense boundary to stream a fallback immediately during navigation, while error.js is explicitly a client-side Error Boundary. Distractor A is wrong because loading.js is not limited to client-side navigation, and error.js does not catch errors on the server during SSR.

    Read the full bite: How do loading.js and error.js integrate with Suspense and Error Boundaries?

17. Question 17 of 30

    When designing a near real-time analytics pipeline, why is a tool like Apache Flink often chosen for the processing stage over alternatives?

    • aBecause it uses a micro-batching architecture, which groups data into small batches for simpler fault tolerance and predictable latency.
    • bBecause it provides native stream processing with advanced state management and windowing, enabling low-latency, continuous computations on unbounded data.
    • cBecause it is designed to periodically query a message queue and load the results into a data warehouse in five-minute intervals.
    • dBecause it is a lightweight library that integrates directly into an application, avoiding the operational overhead of a separate cluster.
    Show the answer

    Answer: b · Because it provides native stream processing with advanced state management and windowing, enabling low-latency, continuous computations on unbounded data.

    Apache Flink is chosen for its native stream processing model that enables true, low-latency computation. The most tempting distractor describes Spark Streaming's micro-batch model, which has slightly higher latency by design.

    Read the full bite: Design a Near Real-Time Analytics Pipeline

18. Question 18 of 30

    When designing a near real-time analytics pipeline for a critical metric, what is the primary trade-off compared to a traditional batch processing system?

    • aReduced need for specialized data stores but slower data ingestion rates.
    • bEnhanced data consistency across systems but with reduced data throughput capacity.
    • cSignificantly lower data latency at the cost of higher operational complexity and infrastructure.
    • dSimplified data model design but a greater risk of data loss during processing.
    Show the answer

    Answer: c · Significantly lower data latency at the cost of higher operational complexity and infrastructure.

    The card emphasizes that stream processing provides low latency but entails higher operational costs and complexity. Batch systems, while simpler and cheaper, introduce significantly higher latency, making option C the direct trade-off highlighted.

    Read the full bite: Design a near real-time analytics pipeline for a critical metric

19. Question 19 of 30

    For a real-time dashboard requiring sub-second query responses on high-volume mobile events, which data store is the most suitable final sink for the processed data?

    • aAmazon S3
    • bApache Druid
    • cPostgreSQL
    • dAmazon Redshift
    Show the answer

    Answer: b · Apache Druid

    Apache Druid is an OLAP database specifically designed for fast aggregations and sub-second queries on time-series data, making it ideal for interactive dashboards. A data warehouse like Amazon Redshift is a tempting but incorrect choice as it's typically not optimized for this level of low-latency querying.

    Read the full bite: Design a Real-Time Analytics Pipeline for Mobile Events

20. Question 20 of 30

    Which technology is specifically designed to serve as the final analytical data store for a real-time mobile event pipeline requiring sub-second query latency on high-volume, time-series data?

    • aPostgreSQL
    • bApache Kafka
    • cApache Druid
    • dApache Hadoop HDFS
    Show the answer

    Answer: c · Apache Druid

    Apache Druid is explicitly mentioned as a real-time OLAP datastore designed for fast analytical queries over time-series data and high-volume ingestion, making it ideal for this scenario. PostgreSQL is a general-purpose OLTP database unsuitable for the analytical query patterns and high ingest volume required, while Kafka is an ingestion layer and HDFS is a batch-oriented storage system.

    Read the full bite: Design a Real-Time Analytics Pipeline for Mobile Events

21. Question 21 of 30

    During streaming SSR in the Next.js App Router, what does loading.js do when a Server Component suspends on a slow data fetch?

    • aIt blocks HTML emission until all data promises resolve, similar to getServerSideProps.
    • bIt provides a client-side fallback using useState and useEffect while the server request completes.
    • cIt requires the developer to manually wrap the route in a Suspense boundary to display the fallback.
    • dIt automatically wraps the route segment in a Suspense boundary so the server streams the shell first.
    Show the answer

    Answer: d · It automatically wraps the route segment in a Suspense boundary so the server streams the shell first.

    loading.js is a framework convention that automatically wraps the route segment in a Suspense fallback, enabling the server to stream the shell instantly while deferring slow data. Option B is a common misconception because loading.js is not a client-side spinner driven by useState or useEffect; it is part of the server streaming architecture.

    Read the full bite: Explain streaming with Server Components, Suspense, and loading.js

22. Question 22 of 30

    Which scenario presents the greatest challenge for effectively applying the DDM algorithm?

    • aMonitoring a real-time ad click-through model where user actions provide immediate feedback.
    • bDetecting abrupt performance shifts in a spam filter with instant user corrections.
    • cIdentifying a slow, subtle degradation in a binary classifier's performance over time.
    • dAnomaly detection in network traffic where system responses offer quick ground truth.
    Show the answer

    Answer: c · Identifying a slow, subtle degradation in a binary classifier's performance over time.

    DDM is explicitly stated to be less effective for detecting gradual, subtle drift, making a slow degradation a significant challenge. The other scenarios involve immediate feedback and abrupt changes, which are ideal conditions for DDM.

    Read the full bite: DDM: Detecting Drift with Error Rate Statistics

23. Question 23 of 30

    Your real-time news dashboard must serve the global top 10 in under 100ms during viral traffic spikes. Which architectural choice correctly implements the hot path?

    • aIngest views into a scalable stream, have a real-time engine compute sliding-window aggregates, and serve the pre-computed top 10 from an in-memory cache with TTL eviction
    • bHave the web tier write views to a relational database and execute a SQL GROUP BY article_id ORDER BY count DESC LIMIT 10 on every page load
    • cArchive events to object storage via a delivery stream, run scheduled analytics queries to refresh the top 10, and serve the dashboard from that cached result
    • dStore every raw view event in a hot cache and scan the entire set to compute the top 10 on each dashboard request
    Show the answer

    Answer: a · Ingest views into a scalable stream, have a real-time engine compute sliding-window aggregates, and serve the pre-computed top 10 from an in-memory cache with TTL eviction

    Pre-computing windowed aggregates in a stream processor and serving only the top ten from a low-latency cache guarantees sub-100ms reads under millions of events per minute. Option C mistakenly applies the cold-path analytics pattern to live serving, while A and B compute or scan on read, causing latency and memory to spike with traffic.

    Read the full bite: Design a real-time top-10 dashboard for a global news site

24. Question 24 of 30

    Why does a clickstream system typically fan out from one ingestion log into separate real-time and batch paths?

    • aTo duplicate data for backup in case the log is lost
    • bTo avoid using object storage, which cannot hold event data
    • cBecause low-latency dashboards and full-history ad-hoc analysis have conflicting storage needs
    • dBecause a single stream processor cannot read from Kafka
    Show the answer

    Answer: c · Because low-latency dashboards and full-history ad-hoc analysis have conflicting storage needs

    Live dashboards need second-level latency on aggregates while data scientists need flexible queries over raw history; no single store serves both well, so the pipeline splits paths after a shared log.

    Read the full bite: Clickstream architecture for real-time and batch

25. Question 25 of 30

    What does 'exactly-once' actually guarantee in a streaming pipeline?

    • aMessages are never duplicated because retries are disabled entirely
    • bEvery event is processed within a fixed latency budget
    • cEach event affects downstream state and output exactly once despite retries
    • dEach message is physically transmitted over the network exactly one time
    Show the answer

    Answer: c · Each event affects downstream state and output exactly once despite retries

    Exactly-once is about effects: an event is reflected in state and output once even if delivered multiple times, achieved via idempotency or transactional commits. The network may still deliver duplicates.

    Read the full bite: Exactly-once semantics in stream processing

26. Question 26 of 30

    Why aggregate streaming windows on event time with watermarks rather than on processing time?

    • aProcessing time is harder to extract from records
    • bEvent time removes the need to retain any window state
    • cWatermarks eliminate all late data automatically
    • dEvent time plus watermarks places out-of-order records in their true window within a tolerated lateness
    Show the answer

    Answer: d · Event time plus watermarks places out-of-order records in their true window within a tolerated lateness

    Event-time windowing with watermarks assigns delayed records to the correct window up to an allowed lateness, giving accurate results. Watermarks do not delete late data, and windows still require retained state during the grace period.

    Read the full bite: Handling late data in streaming windows

27. Question 27 of 30

    In a Next.js App Router Route Handler, which approach correctly streams a large text response using the standard Web Streams API without buffering the entire payload?

    • aUse res.write from the Node.js response object to send chunks incrementally
    • bCreate a ReadableStream with a controller, encode string chunks via TextEncoder into Uint8Array, enqueue them, and return the stream in a new Response
    • cBuffer the full response in memory, split it into chunks, and enqueue them into a ReadableStream
    • dPipe a Node fs.createReadStream directly into the Response body
    Show the answer

    Answer: b · Create a ReadableStream with a controller, encode string chunks via TextEncoder into Uint8Array, enqueue them, and return the stream in a new Response

    The correct approach uses the Web Streams API ReadableStream with TextEncoder to send Uint8Array chunks in a standard Response, which is the App Router pattern. Using res.write relies on the Node.js response object from Pages Router and does not apply to Route Handlers, which expect a Web Response.

    Read the full bite: How do you implement response streaming in a Next.js Route Handler?

28. Question 28 of 30

    In a personalized ad pipeline, which work is best done in a real-time streaming layer rather than batch?

    • aNightly retraining of the recommendation model
    • bAggregating last quarter's purchase totals
    • cComputing a user's lifetime category affinities
    • dCapturing current-session browsing intent for immediate scoring
    Show the answer

    Answer: d · Capturing current-session browsing intent for immediate scoring

    Current-session intent is time-sensitive and must be captured live to influence the next ad, so it belongs in streaming. Lifetime affinities and quarterly aggregates are heavy, slow-changing computations suited to batch.

    Read the full bite: Design a personalized ad copy pipeline

29. Question 29 of 30

    Why can't standard ASGI middleware simply add a header derived from the response body without buffering?

    • aHeaders in ASGI are immutable objects
    • bResponse bodies are encrypted until they reach the client
    • cThe http.response.start message with headers is sent before the body chunks stream, so the body is not yet known when headers commit
    • dASGI forbids middleware from modifying headers entirely
    Show the answer

    Answer: c · The http.response.start message with headers is sent before the body chunks stream, so the body is not yet known when headers commit

    ASGI emits headers in the start message ahead of the streamed body chunks, so a body-derived header requires buffering all chunks, then sending the modified start. Headers are not inherently immutable or forbidden; it is the send ordering that forces buffering.

    Read the full bite: Reading the full response body in middleware

30. Question 30 of 30

    A large e-commerce platform requires both precise daily sales reports and immediate, up-to-the-minute inventory updates. Which architecture best fits this need?

    • aA Lambda Architecture
    • bA pure stream processing architecture
    • cA pure batch processing architecture
    • dA microservices-based architecture
    Show the answer

    Answer: a · A Lambda Architecture

    Lambda Architecture uniquely combines a batch layer for historical accuracy and a stream layer for real-time insights, addressing both needs simultaneously. Pure batch or stream systems only satisfy one requirement.

    Read the full bite: Lambda Architecture: Batch and Stream for Big Data