Practice data streaming architecture vocabulary: Lambda vs. Kappa architecture, speed and batch layers, real-time views, and architectural trade-offs.
0 / 10 completed
1 / 10
What are the two processing layers in a Lambda architecture?
Lambda architecture combines a batch layer — which reprocesses all historical data periodically for accuracy — and a speed layer — which processes incoming events in real-time with lower latency but potentially less accuracy. Query results are merged from both layers. The trade-off is complexity: maintaining two separate processing codebases.
2 / 10
What is the key principle of Kappa architecture?
Kappa architecture (Nathan Marz, 2014) simplifies Lambda by using only a streaming layer. Historical data reprocessing is handled by replaying the event log (e.g., a Kafka topic) through the same streaming pipeline. This eliminates the complexity of maintaining two separate codebases but requires a durable, replayable event log.
3 / 10
'The speed layer provides real-time views.' What is a real-time view in this context?
In Lambda architecture, the speed layer computes real-time views from the most recent events — the data that the batch layer hasn't yet processed. These views may be less accurate (due to late data or approximate algorithms) but are available with low latency. The serving layer merges batch views and real-time views to answer queries.
4 / 10
'We chose Kappa for operational simplicity.' What operational complexity does Kappa avoid compared to Lambda?
Lambda's main operational burden is maintaining two codebases — a batch pipeline (often Hadoop/Spark) and a streaming pipeline (often Flink/Storm) — and ensuring they produce consistent results. When business logic changes, both must be updated in sync. Kappa eliminates this by using one streaming pipeline for everything, at the cost of needing a durable replayable log.
5 / 10
What is a key trade-off when choosing between Lambda and Kappa architecture?
The core Lambda vs. Kappa trade-off is complexity vs. capability. Lambda's two-layer approach handles reprocessing naturally (just rerun the batch layer) but requires maintaining two pipelines. Kappa is simpler operationally but requires your streaming system to efficiently replay large volumes of historical data — which works well with Kafka but adds pressure on the streaming engine.
6 / 10
Review Comment: 'The Kafka consumer group isn't scaling effectively. We're seeing a high degree of token contention on the topic 'orders'. What does this likely indicate about our stream processing setup?',
This comment focuses on a practical issue – high token contention. This strongly suggests that the consumer group isn't being efficiently parallelized across multiple instances. Option A addresses resource constraints but doesn't directly explain the token contention observed in Kafka; options C and D are related to schema or ordering, not the core issue of consumer parallelism.
7 / 10
Slack Message from Alex (Lead Developer): 'Just deployed a new version of our fraud detection stream. It's now pulling data directly from the EventBridge service and processing it with Flink. We're aiming for near real-time alerts based on complex event patterns.'
The key here is 'data integration service.' EventBridge isn't a typical message queue; it's designed to connect disparate services and facilitate data flow. Flink then consumes this data stream. Options A and C are incorrect—EventBridge doesn't buffer events or manage scaling.
8 / 10
PR Description for a Stream Processing Job: 'Implemented a new state backend using RocksDB to improve the efficiency of our real-time inventory updates. The stream now uses a windowed aggregation on the 'product_id' field, calculating daily sales totals.'
This describes a common pattern in stream processing – using a state backend like RocksDB. RocksDB allows Flink to maintain the state of calculations (e.g., windowed aggregations) efficiently, which is crucial for performance and scalability when dealing with constantly changing data streams.
9 / 10
Standup Update from Ben (Data Engineer): 'We're currently migrating our customer purchase events from a batch system to a Kafka stream. We're using KSQLdb for real-time transformations before sending the data to Snowflake for reporting.'
The core of this statement is about using KSQLdb for *real-time transformations*. It's a streaming SQL engine that sits on top of the Kafka stream to preprocess the data before it's loaded into Snowflake. Option A misrepresents KSQLdb's role; options C and D are incorrect regarding replication or decommissioning.
10 / 10
API Response from a Stream Processing Monitoring Tool: `{'stream_name': 'user_activity', 'latency': 25ms, 'throughput': 10000 events/sec, 'token_contention': 'high'}
This response provides key metrics. The 'high' token contention flag is a critical indicator – it means the consumer group isn't scaling efficiently, directly impacting performance. This allows the developer to investigate the parallelism configuration or resource allocation.
What will I learn from the "Data Streaming Architecture Vocabulary" exercise?
Practice data streaming architecture vocabulary: Lambda vs. Kappa architecture, speed and batch layers, real-time views, and architectural trade-offs.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Streaming Data exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss streaming data topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Streaming Data exercises?
See the full Streaming Data exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.