Practice reading and describing data pipeline metrics — events per second, ingestion rates, consumer lag, job SLAs. {TOTAL} exercises.
0 / 10 completed
1 / 10
A data engineer describes their pipeline's capacity to a stakeholder.
"The pipeline currently processes 50,000 events per second at peak load, ingests approximately 3 TB of raw data daily, and has an end-to-end processing latency of under 4 minutes from event ingestion to the data warehouse."
Which of the following is the most concise and accurate paraphrase of this statement?
Option B is correct because it: • Translates "50,000 events per second" into plain speech: "50 thousand events every second" • Explains "ingests 3 TB daily" in natural phrasing: "store about 3 terabytes of raw data per day" • Re-states "end-to-end processing latency of under 4 minutes" as a practical outcome: "data is available in the warehouse within 4 minutes of being collected"
Why option C is weaker: It just lists the numbers without connecting them to meaning. The goal of paraphrasing data pipeline metrics is to help the listener understand the capability and impact.
Key vocabulary: • events per second (EPS) — the rate at which events (logs, messages, clicks, transactions) enter a system • ingestion — the process of collecting and importing data into a storage or processing system • end-to-end latency — time from when data enters the pipeline to when it reaches its final destination • raw data — unprocessed data before transformation, cleaning, or aggregation • data warehouse — a central repository storing structured, processed data for analytics
Common IT phrases for pipeline capacity: • "The pipeline handles X events per second." • "We process roughly X terabytes of data per day." • "The end-to-end latency is currently around X minutes."
2 / 10
During a sprint review, a data engineer says:
"Last week our Kafka consumer lag spiked to 2.8 million messages during the Tuesday morning traffic peak. Our consumers were processing 12,000 messages per second but the producers were writing at 18,500 per second — a 54% throughput gap."
What is the engineer describing?
Consumer lag explained: Consumer lag is the difference between where the producer is writing (the latest offset) and where the consumer has read up to (the committed offset). A lag of 2.8 million means 2.8 million messages are waiting to be processed.
Why this matters: • Producers: 18,500 msg/sec → Consumers: 12,000 msg/sec • Throughput gap: (18,500 − 12,000) ÷ 18,500 ≈ 35% (the engineer rounded to "54%" — this is the gap relative to consumer throughput: (18,500 − 12,000) ÷ 12,000... actually ≈ 54%) • At this rate, the backlog grows by 6,500 messages every second = 390,000/min = 23M/hour
Key vocabulary: • Kafka — a distributed event streaming platform; widely used for high-throughput data pipelines • consumer lag — how far behind a Kafka consumer is from the latest message; a key health metric • producer — the component writing messages to Kafka (or a queue) • consumer — the component reading and processing messages from Kafka • offset — the position of a message in a Kafka partition (like a log index) • throughput gap — the difference between production rate and consumption rate
Useful phrases: • "Our consumer lag spiked to X million messages during the peak window." • "Producers are outpacing consumers — we need to scale up the consumer group." • "We need to provision more consumer instances to close the throughput gap."
3 / 10
A data platform team reports their monthly metrics in a business review:
"In April we processed 4.7 billion events — up 23% month-over-month. Average batch job duration was 47 minutes with a p95 of 2 hours 14 minutes. The pipeline SLA of 99.5% data freshness within 1 hour was met on 29 out of 30 days."
Which phrase best describes the pipeline's reliability performance?
Option C is correct because it: • States the SLA achievement as a rate: 29/30 = 96.7% of days (not just "mostly") • Names the metric being measured: "1-hour data freshness SLA" • Combines the reliability result with the growth context that makes it meaningful • Uses the correct phrase "missed it once" rather than saying "was late" (which is informal)
Calculating SLA compliance: 29 out of 30 days = 96.7% of days — which is BELOW the stated 99.5% SLA (if interpreted as a monthly target). This is a nuance worth flagging in a review.
Key vocabulary: • data freshness — how recently data was updated; often expressed as a maximum allowed lag (e.g. "data must be under 1 hour old") • batch job — a process that runs at scheduled intervals, processing data in bulk (vs real-time streaming) • p95 duration — 95% of batch jobs complete within this time; 5% take longer • SLA compliance — the degree to which a service meets its agreed-upon targets • month-over-month (MoM) — comparison between the current month and the previous month
Common data pipeline review phrases: • "We processed X events this month — up Y% month-over-month." • "The pipeline met its SLA on X out of Y days." • "P95 job duration is within our 4-hour budget."
4 / 10
An engineer writes the following in a design doc:
"The proposed pipeline must handle peak write throughput of 85,000 records/second, support horizontal scaling to 500 GB/hour ingestion, and maintain end-to-end latency under 500ms for 99% of events."
Which set of numbers correctly paraphrases this capacity requirement?
Option A is correct because it: • States the read unit correctly: "per second" not "per minute" • Converts 500 GB/hour to a daily figure for context: 500 × 24 = 12,000 GB = ~12 TB/day • Explains "end-to-end latency under 500ms for 99% of events" as "99% of events processed within half a second" — this is clearer for a non-technical stakeholder
Why option D is insufficient: Option D just repeats the abbreviations without explaining them. Design docs should be precise, but verbal summaries and stakeholder communications need translation.
Key vocabulary: • write throughput — the rate at which new data is written to a system • horizontal scaling — adding more machines to handle load (vs vertical scaling = larger machine) • ingestion rate — how fast data enters the system; often expressed in GB/hour or records/sec • end-to-end latency — total time from data creation to final availability in the destination • p99 latency — "latency under 500ms for 99% of events" = p99 latency ≤ 500ms
5 / 10
A team's pipeline performance review shows the following for the past month:
Metric
Target
Actual
Daily volume
≥ 2B events/day
2.4B events/day
Data freshness (p99)
≤ 30 min
22 min
Job success rate
≥ 99.5%
97.8%
Failed job recovery (MTTR)
≤ 15 min
41 min
Which metrics are not meeting their SLAs?
Reading the table: • Daily volume: 2.4B ≥ 2B target ✅ Exceeds target • Data freshness: 22 min ≤ 30 min target ✅ Meets target (with 8-min buffer) • Job success rate: 97.8% < 99.5% target ❌ Below target by 1.7 percentage points • Failed job recovery (MTTR): 41 min > 15 min target ❌ Almost 3× the target
Business impact: A 97.8% job success rate means 2.2% of jobs fail. If running 1,000 jobs per day, that's 22 failed jobs per day. An MTTR of 41 minutes instead of 15 means each failure causes 26 extra minutes of delay — directly impacting data freshness for downstream consumers.
Key vocabulary: • SLA breach — when an actual metric value falls short of the agreed target • MTTR (Mean Time To Recovery) — average time to recover from a failed job or service; also used as "Mean Time To Repair" • job success rate — percentage of scheduled pipeline jobs that complete without errors • data freshness — how current the data is; described as a maximum allowed age or lag • downstream consumers — systems, dashboards, or teams that depend on pipeline output
How to report this at a meeting: • "We missed two SLAs this month: job success rate was 97.8% against a 99.5% target, and MTTR for failed jobs was 41 minutes — almost three times our 15-minute target." • "We need to focus on pipeline stability — volume and freshness are green, but reliability is lagging."
6 / 10
Review Comment: 'The `data_ingestion.py` script's logs show a significant spike in latency – average processing time jumped from 0.5 seconds to 3.2 seconds last night. The metrics dashboard indicates an increased queue depth of 15,000 messages for the 'user_events' topic. What's the most likely root cause based on this information?'
The comment highlights a dramatic increase in latency and queue depth. A surge in incoming traffic is the most probable cause given the correlation between increased volume and processing time. While memory issues or serialization problems could contribute, they wouldn't explain the rapid spike as directly.
7 / 10
Slack Message from @johndoe: 'Hey team, we're seeing some weirdness with the nightly ETL job. The `customer_data` table in Snowflake is showing a lot of duplicate records – almost 20% duplication rate! The pipeline's error logs show increased retries for the 'transform' stage. What metric should we investigate *first*?'
Duplicate records in a transformed dataset almost always point to issues within the transformation logic itself. Increasing retries suggests the transformation stage is struggling to process data efficiently or encountering errors that trigger retry mechanisms. While table size or network latency could be factors, they're less directly linked to duplicated records.
8 / 10
PR Description: 'Implemented a new rate limiting mechanism for the `product_recommendations` pipeline to prevent overload during peak traffic. Introduced a Redis cache with an eviction policy of LRU (Least Recently Used). The goal is to reduce latency by 15% and ensure consistent performance under high load. The key metric we'll monitor post-deployment is…'
The PR focuses on latency reduction and consistent performance. Therefore, monitoring the *average response time* for recommendation queries is the most relevant metric to assess the impact of the implemented rate limiting and caching strategy. While other metrics are important, they don't directly measure the primary goal.
9 / 10
Standup Update from @sarah: 'Yesterday, our data quality checks on the `order_transactions` pipeline failed. We saw a 12% failure rate due to invalid date formats in the incoming data. The pipeline is currently handling approximately 8 million transactions per day, and we're seeing increased latency during peak hours. What's the most immediate action?'
The primary issue is invalid date formats causing quality checks to fail. Implementing *stricter data validation rules* directly addresses this root cause. While scaling or throttling could mitigate symptoms, they don't fix the underlying problem of bad data being processed.
10 / 10
API Response (Pipeline Metrics Endpoint):{ "pipeline_name": "inventory_updates", "timestamp": "2024-10-27T10:00:00Z", "throughput": 35000, "errors": 12, "latency_99th_percentile": "120 seconds" }. The latency value is given in what unit?
The API response clearly indicates that `latency_99th_percentile` represents the 99th percentile of latency measured in *seconds*. Understanding the units is critical for interpreting and comparing pipeline performance metrics.
What will I practise in "Data Pipeline Numbers in English"?
This module focuses on Numbers, Data & Metrics — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Numbers, Data & Metrics exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around numbers, data & metrics — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Numbers, Data & Metrics exercises?
See the Numbers, Data & Metrics hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.