Data Product Design Vocabulary
Practice data product design vocabulary: output ports, SLA freshness guarantees, schema versioning, observability instrumentation, and catalog discoverability.
0 / 22 completed
1 / 22
Your data mesh design doc says 'The data product has a clearly defined output port.' What is an output port in data mesh?
In data mesh, an output port is the well-defined interface consumers use to access data. It hides the internal implementation and provides a stable contract — the producer team can change internals without breaking consumers as long as the output port contract is maintained.
2 / 22
A data product spec says 'The data product SLA guarantees freshness.' What does freshness mean in this context?
Data freshness SLA defines the maximum lag — e.g., 'data is no more than 4 hours old.' Consumers need to know this to decide if the data product meets their latency requirements. A stale data product may be fine for trend reports but not for real-time dashboards.
3 / 22
Your team says 'The data product schema is versioned.' Why is schema versioning important for data products?
Data products are consumed by many downstream teams. Schema versioning lets consumers pin to a version (e.g., v1) while the producer ships v2 with breaking changes — giving consumers a migration window instead of forcing immediate updates that break their pipelines.
4 / 22
A data product review recommends 'adding observability instrumentation.' What should data product observability cover?
Data product observability tracks data health — not just pipeline health. Key dimensions: freshness (is the data current?), volume (are row counts as expected?), quality (are null rates and schema violations within bounds?), and lineage (where did this data come from?). These are equivalent to uptime/latency/errors for services.
5 / 22
A data catalog team says 'Data product discoverability in the catalog is a first-class requirement.' Why?
In data mesh, the data catalog is the discovery layer. Consumers must be able to find data products, understand their schemas, check SLAs, see ownership, and access documentation — all without asking the producing team. Without good discoverability, the self-serve model breaks down.
6 / 22
PR Description:
"Just updated the customer_orders API endpoint. Added a new field called `delivery_status` to reflect the current state of each order (e.g., 'pending', 'shipped', 'delivered'). This makes it easier for our frontend team to display real-time shipping information."The question tests understanding of communicating data product changes effectively. While option B highlights a good aspect (clear communication), it misses the crucial point that the description *doesn't* explain how the
delivery_status field is actually managed or updated. Options A and C correctly identify deficiencies in the PR description, failing to address the need for details about data updates and triggers. Option D incorrectly uses 'real-time,' which isn't a technical requirement but rather an expectation.7 / 22
JSON Schema validation is a critical technique for ensuring data integrity within a data product. While OpenAPI documentation provides a human-readable description of the API's structure, it doesn't automatically enforce that structure; Schema validation uses a machine-defined schema to rigorously check incoming and outgoing data against its rules – this prevents inconsistencies and errors arising from incorrect data types or missing fields. The team lead is advocating for proactive data quality control at the service layer.
8 / 22
During a discussion about this change, a senior developer asks: 'We're exposing `delivery_status` as a string. How do we ensure that the backend consistently uses these values – 'pending', 'shipped', 'delivered' – and doesn't start returning arbitrary strings if the logic changes later?' Which of the following best describes the technique to address this concern?
The correct answer is 'Use a configuration management system to enforce allowed values for
delivery_status.' This approach directly addresses the risk of inconsistent data by centralizing and controlling the possible string values. Options A and B are valuable practices but don't specifically solve the problem of dynamic schema changes. Option D, documentation alone, isn't sufficient to prevent incorrect data being returned; it only provides guidance. Configuration management ensures a controlled environment regardless of future API logic modifications.9 / 22
PR Description:
"Just updated the customer_orders API endpoint. Added a new field called `delivery_status` to reflect the current state of each order (e.g., 'pending', 'shipped', 'delivered'). This makes it easier for our frontend team to display real-time shipping information."The question tests understanding of communicating data product changes effectively. While option B highlights a good aspect (clear communication), it misses the crucial point that the description *doesn't* explain how the
delivery_status field is actually managed or updated. Options A and C correctly identify deficiencies in the PR description, failing to address the need for details about data updates and triggers. Option D incorrectly uses 'real-time,' which isn't a technical requirement but rather an expectation.10 / 22
JSON Schema validation is a critical technique for ensuring data integrity within a data product. While OpenAPI documentation provides a human-readable description of the API's structure, it doesn't automatically enforce that structure; Schema validation uses a machine-defined schema to rigorously check incoming and outgoing data against its rules – this prevents inconsistencies and errors arising from incorrect data types or missing fields. The team lead is advocating for proactive data quality control at the service layer.
11 / 22
During a discussion about this change, a senior developer asks: 'We're exposing `delivery_status` as a string. How do we ensure that the backend consistently uses these values – 'pending', 'shipped', 'delivered' – and doesn't start returning arbitrary strings if the logic changes later?' Which of the following best describes the technique to address this concern?
The correct answer is 'Use a configuration management system to enforce allowed values for
delivery_status.' This approach directly addresses the risk of inconsistent data by centralizing and controlling the possible string values. Options A and B are valuable practices but don't specifically solve the problem of dynamic schema changes. Option D, documentation alone, isn't sufficient to prevent incorrect data being returned; it only provides guidance. Configuration management ensures a controlled environment regardless of future API logic modifications.12 / 22
PR Description:
"Just updated the customer_orders API endpoint. Added a new field called `delivery_status` to reflect the current state of each order (e.g., 'pending', 'shipped', 'delivered'). This makes it easier for our frontend team to display real-time shipping information."The question tests understanding of communicating data product changes effectively. While option B highlights a good aspect (clear communication), it misses the crucial point that the description *doesn't* explain how the
delivery_status field is actually managed or updated. Options A and C correctly identify deficiencies in the PR description, failing to address the need for details about data updates and triggers. Option D incorrectly uses 'real-time,' which isn't a technical requirement but rather an expectation.13 / 22
JSON Schema validation is a critical technique for ensuring data integrity within a data product. While OpenAPI documentation provides a human-readable description of the API's structure, it doesn't automatically enforce that structure; Schema validation uses a machine-defined schema to rigorously check incoming and outgoing data against its rules – this prevents inconsistencies and errors arising from incorrect data types or missing fields. The team lead is advocating for proactive data quality control at the service layer.
14 / 22
During a discussion about this change, a senior developer asks: 'We're exposing `delivery_status` as a string. How do we ensure that the backend consistently uses these values – 'pending', 'shipped', 'delivered' – and doesn't start returning arbitrary strings if the logic changes later?' Which of the following best describes the technique to address this concern?
The correct answer is 'Use a configuration management system to enforce allowed values for
delivery_status.' This approach directly addresses the risk of inconsistent data by centralizing and controlling the possible string values. Options A and B are valuable practices but don't specifically solve the problem of dynamic schema changes. Option D, documentation alone, isn't sufficient to prevent incorrect data being returned; it only provides guidance. Configuration management ensures a controlled environment regardless of future API logic modifications.15 / 22
PR Description:
"Just updated the customer_orders API endpoint. Added a new field called `delivery_status` to reflect the current state of each order (e.g., 'pending', 'shipped', 'delivered'). This makes it easier for our frontend team to display real-time shipping information."The question tests understanding of communicating data product changes effectively. While option B highlights a good aspect (clear communication), it misses the crucial point that the description *doesn't* explain how the
delivery_status field is actually managed or updated. Options A and C correctly identify deficiencies in the PR description, failing to address the need for details about data updates and triggers. Option D incorrectly uses 'real-time,' which isn't a technical requirement but rather an expectation.16 / 22
JSON Schema validation is a critical technique for ensuring data integrity within a data product. While OpenAPI documentation provides a human-readable description of the API's structure, it doesn't automatically enforce that structure; Schema validation uses a machine-defined schema to rigorously check incoming and outgoing data against its rules – this prevents inconsistencies and errors arising from incorrect data types or missing fields. The team lead is advocating for proactive data quality control at the service layer.
17 / 22
During a discussion about this change, a senior developer asks: 'We're exposing `delivery_status` as a string. How do we ensure that the backend consistently uses these values – 'pending', 'shipped', 'delivered' – and doesn't start returning arbitrary strings if the logic changes later?' Which of the following best describes the technique to address this concern?
The correct answer is 'Use a configuration management system to enforce allowed values for
delivery_status.' This approach directly addresses the risk of inconsistent data by centralizing and controlling the possible string values. Options A and B are valuable practices but don't specifically solve the problem of dynamic schema changes. Option D, documentation alone, isn't sufficient to prevent incorrect data being returned; it only provides guidance. Configuration management ensures a controlled environment regardless of future API logic modifications.18 / 22
Sarah, the data product owner, sends this Slack message: 'I'm seeing a lot of requests for changes to the `customer_orders` API. It feels like we're constantly patching it instead of building a robust, well-defined product. What's your take on introducing a stable API versioning strategy?' Considering Sarah's concern, which response best reflects a proactive approach to managing data product evolution?
Sarah is highlighting a common issue: reactive development. API versioning (option 1) avoids this by providing a structured way to manage changes and ensure clients can adapt. While discussing impact (option 3) is valuable, the core of her concern requires advocating for a proactive strategy – backward compatibility with clear deprecation policies (option 2).
19 / 22
You're writing the PR description for an update to a data product that exposes order tracking information. The description reads: 'This change adds support for retrieving delivery status updates via a new API endpoint. This allows downstream systems to react to changes in the delivery process, improving real-time visibility.' Which of the following statements best captures the *primary* benefit of this feature from a data product design perspective?
The description focuses on 'reacting to changes' – this directly relates to observability. While the other options are potential benefits, they aren't the *primary* reason for adding a delivery status endpoint; it's about enabling real-time responses and triggering actions based on data updates. This aligns with the core concept of data product observability.
20 / 22
During a code review, your team lead says: 'The new `product_catalog` API returns all product attributes as a single JSON object. This isn't ideal because it makes it difficult to query for specific product features – we need a more granular schema.' Considering this feedback, what is the *most* important design consideration moving forward?
The team lead's comment highlights the problem of a flat JSON structure. To address this, the core design consideration is to separate attributes into distinct fields within the schema (option 3), allowing for more targeted queries and efficient data retrieval – this directly addresses the need for granular querying.
21 / 22
During a daily stand-up, David asks: 'We're building a new data product that aggregates customer purchase history. We're storing the transaction timestamps as Unix epoch seconds in our database. How can we ensure consistency across different systems that consume this data – particularly when dealing with potential timezone differences?' Which of the following approaches is MOST appropriate?
While UTC (option 1) is often recommended, it shifts the responsibility and potential for error onto the consumers. Option 3 – using ISO 8601 strings with timezone information – provides the most flexibility and clarity, allowing both the producer and consumer to handle timezones consistently. Documenting the strategy (option 2) ensures everyone understands how it's handled.
22 / 22
You receive this message from a junior developer: 'I'm getting an error when trying to access the new `product_metrics` API. The response is empty.' What's the *best* initial troubleshooting step you should advise them to take, considering data product observability?
The core of observability is understanding *why* a response is empty. Focusing on the request parameters (option 2) allows you to quickly identify potential issues with incorrect formatting or missing required fields – this is the first step in diagnosing the problem and correlating it with the API's behavior. While other options are important, they address symptoms rather than root causes.
Frequently Asked Questions
What does the "Data Product Design Vocabulary" exercise practise?
Practice data product design vocabulary: output ports, SLA freshness guarantees, schema versioning, observability instrumentation, and catalog discoverability.
How many questions are in this exercise?
This exercise has 22 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Data Mesh Architecture category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Data Product Design Vocabulary" part of a larger series?
Yes — it's one exercise in the Data Mesh Architecture category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Data Mesh Architecture category page for related exercises, or browse the main Exercises hub for other IT English topics.