Scenario: "The Avro schema is backward compatible." What does backward compatibility mean in schema evolution?
Mode
Old reads New
New reads Old
Backward
✓ Yes
—
Forward
—
✓ Yes
Full
✓ Yes
✓ Yes
Key vocab:backward compatibility, forward compatibility, full compatibility, schema registry.
2 / 14
Scenario: "Adding a required field to a Protobuf message breaks backward compatibility." Why?
Protobuf best practice: never use required (deprecated in proto3). All fields are optional with defaults in proto3. Removing a field: reserve the field number to prevent tag reuse.
Key vocab:required vs. optional in Protobuf, field tag number reservation, proto3 optional default.
3 / 14
Scenario: "Confluent Schema Registry enforces FULL_TRANSITIVE compatibility." What does transitive add over standard full compatibility?
Compatibility chain: v1→v2→v3 can be locally fully compatible, but v1 consumers may not read v3 data if intermediate changes compound. Transitive checking catches this.
Scenario: "The team adopted an expansion-then-contraction pattern for the schema migration." What is this pattern?
Expand/contract: the only safe way to rename a column without downtime. Dual-write period: populate both old and new columns simultaneously until all consumers migrate.
Scenario: "Schema drift was detected in the daily pipeline run." What is schema drift?
Schema drift detection: compare actual data profile against registered schema each run. Tools: Great Expectations, Soda Core, dbt schema tests. Alert on: new columns, missing columns, type changes.
During a code review of a new microservice API, Sarah points out that the team's recent schema evolution strategy – using versioning and backwards compatibility – is now causing significant integration issues with older clients. The lead developer, Mark, explains he's been focusing on adding new fields incrementally to maintain a single source of truth for the data model, without considering the impact on existing consumers. Which of the following best describes the core problem Mark faces?
Mark's approach highlights a critical misunderstanding: backwards compatibility isn't just about adding features; it's about ensuring existing clients can continue to consume the API without modification. By focusing solely on a single source of truth, he hasn't accounted for the fact that older clients rely on specific field definitions. The correct answer emphasizes the importance of considering consumer compatibility during schema evolution – a key principle often overlooked in prioritizing new features.
7 / 14
During a code review of a new microservice API, Sarah points out that the team's recent schema evolution strategy – using versioning and backwards compatibility – is now causing significant integration issues with older clients. The lead developer, Mark, explains he's been focusing on adding new fields incrementally to maintain a single source of truth for the data model, without considering the impact on existing consumers. Which of the following best describes the core problem Mark faces?
Mark's approach highlights a critical misunderstanding: backwards compatibility isn't just about adding features; it's about ensuring existing clients can continue to consume the API without modification. By focusing solely on a single source of truth, he hasn't accounted for the fact that older clients rely on specific field definitions. The correct answer emphasizes the importance of considering consumer compatibility during schema evolution – a key principle often overlooked in prioritizing new features.
8 / 14
During a code review of a new microservice API, Sarah points out that the team's recent schema evolution strategy – using versioning and backwards compatibility – is now causing significant integration issues with older clients. The lead developer, Mark, explains he's been focusing on adding new fields incrementally to maintain a single source of truth for the data model, without considering the impact on existing consumers. Which of the following best describes the core problem Mark faces?
Mark's approach highlights a critical misunderstanding: backwards compatibility isn't just about adding features; it's about ensuring existing clients can continue to consume the API without modification. By focusing solely on a single source of truth, he hasn't accounted for the fact that older clients rely on specific field definitions. The correct answer emphasizes the importance of considering consumer compatibility during schema evolution – a key principle often overlooked in prioritizing new features.
9 / 14
During a code review of a new microservice API, Sarah points out that the team's recent schema evolution strategy – using versioning and backwards compatibility – is now causing significant integration issues with older clients. The lead developer, Mark, explains he's been focusing on adding new fields incrementally to maintain a single source of truth for the data model, without considering the impact on existing consumers. Which of the following best describes the core problem Mark faces?
Mark's approach highlights a critical misunderstanding: backwards compatibility isn't just about adding features; it's about ensuring existing clients can continue to consume the API without modification. By focusing solely on a single source of truth, he hasn't accounted for the fact that older clients rely on specific field definitions. The correct answer emphasizes the importance of considering consumer compatibility during schema evolution – a key principle often overlooked in prioritizing new features.
10 / 14
Mark from the data team sent this Slack message: 'Just noticed schema v3 of our user profile API now includes a `loyalty_tier` field. It's causing all our older microservices to fail – they weren't expecting it!'. Considering Mark's statement, what is the *primary* reason for this incompatibility?
Mark's message highlights a classic scenario of schema evolution causing problems. The core issue is that adding a new, non-backward-compatible field (loyalty_tier) to a newer version of the API breaks compatibility with older microservices that weren't designed to handle it. This demonstrates how changes without considering backwards compatibility can lead to integration failures. Options B and C are incorrect because they misrepresent the root cause – it's not about documentation or intentional design, but the fundamental incompatibility introduced by the new field.
11 / 14
During a standup meeting, David explains: 'We're using a phased approach to schema migration – starting with adding optional fields, then introducing required ones, and finally deprecating older versions. This allows us to minimize disruption.' What is the name of this schema migration pattern?
David's description perfectly illustrates an 'expansion-then-contraction' pattern for schema migration. This strategy involves initially adding optional fields (expanding) to allow older systems to continue functioning while newer systems adopt the changes. Subsequently, required fields are introduced (contraction), and older versions are eventually deprecated, reducing integration risk. The other options represent fundamentally different migration approaches that don't align with this phased, controlled strategy.
12 / 14
The team is reviewing a PR introducing a new version of the order API. The reviewer, Elena, notes: 'The schema change includes a `discount_code` field, but we haven't implemented any validation logic for it in the backend service. This could lead to unexpected behavior if an invalid code is submitted.' What best describes Elena's concern regarding this change?
Elena correctly identifies a critical issue: a lack of validation logic for the new discount_code field. This represents a failure in data integrity enforcement – if the backend doesn't validate the code, it could accept invalid values, leading to incorrect calculations or other unexpected behavior. This highlights the importance of validating new fields when introducing schema changes and ensuring backward compatibility isn't solely reliant on the absence of incompatible features.
13 / 14
You're investigating a situation where the daily pipeline run reports 'schema drift'. According to your team's documentation, schema drift is defined as: 'Changes in the structure or data types of messages that are not formally managed through versioning and compatibility strategies.' Which of the following scenarios would *most likely* trigger this alert?
Schema drift is triggered by *unmanaged* changes to the message structure or data types. Option 2 – where a microservice uses a different data type for order IDs – represents an unmanaged change that would fall under the definition of schema drift. The other options represent formally managed compatibility strategies, such as adding optional fields or updating documentation, which wouldn't trigger the alert.
14 / 14
Sarah is writing a PR description for a schema evolution change. She wants to clearly communicate the impact of the change to other developers. Which statement best summarizes the core concept she should emphasize?
Sarah's PR description should primarily focus on maintaining backward compatibility. This is the most crucial aspect of schema evolution – ensuring that newer versions can still work with older systems without requiring immediate modifications. Option 2 directly addresses this core concept, while the other options represent secondary considerations or misleading statements about the change's purpose.
What does the "Schema Evolution Language" exercise practise?
Practice schema versioning vocabulary: backward compatibility, forward compatibility, Avro/Protobuf evolution, and full compatibility.
How many questions are in this exercise?
This exercise has 14 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 Contracts 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 "Schema Evolution Language" part of a larger series?
Yes — it's one exercise in the Data Contracts 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 Contracts category page for related exercises, or browse the main Exercises hub for other IT English topics.