What is a data schema and why enforce it on ingestion?

What's really being asked

This question tests your understanding of data governance and the practical impact of architectural decisions on data quality. The interviewer wants to see if you think about the entire data lifecycle, from producer to consumer. They are probing whether you recognize that proactive quality control at the start of a pipeline (ingestion) is far more effective and less costly than reactive data cleaning downstream.

The full answer

First, define a data schema as a formal blueprint or contract for data. It specifies the structure, including field names, data types (e.g., string, integer, timestamp), and integrity constraints (e.g., NOT NULL, uniqueness). Second, explain that enforcing this schema at the point of ingestion acts as a critical quality gate, operationalizing the "garbage in, garbage out" principle by rejecting malformed data before it enters the system. Third, connect this directly to analytics quality. Schema enforcement guarantees that data in a warehouse or lakehouse is consistent, predictable, and reliable. This allows analysts and data scientists to trust the data, leading to faster insights and more robust models. Finally, a senior answer acknowledges the trade-offs, mentioning that this approach (schema-on-write) adds some ingestion latency and requires coordination, but saves massive downstream costs.

The mistakes people make

A purely academic definition of a schema without linking it to practical data quality issues is a red flag. Another common mistake is focusing only on relational databases (SQL tables) and ignoring schemas in modern data stack components like event streams (e.g., Avro for Kafka) or data lakes (e.g., Parquet). Simply stating that schemas are "good" without explaining the mechanism (validation, rejection) or the business impact (trustworthy dashboards, reliable ML models) is a weak answer. Failing to discuss what happens to rejected data (e.g., dead-letter queue) also shows a lack of operational thinking.

What usually comes next

Expect questions like: "How would you handle schema evolution, like adding a required field?" to test your knowledge of backward/forward compatibility. Or, "Describe a situation where a flexible, schema-on-read approach might be preferable?" to test your understanding of trade-offs. You might also be asked, "What specific tools have you used to manage and enforce schemas, like a Schema Registry or dbt?"

A concrete example

Imagine an e-commerce orders event stream where the schema requires order_value to be a decimal. A bug in a new app version starts sending order_value as a formatted string like "$99.99". With schema enforcement at the ingestion gateway (e.g., Kafka Connect with a Schema Registry), these malformed events are immediately rejected and routed to a dead-letter queue for investigation. This prevents the downstream revenue dashboard from breaking or, worse, silently miscalculating total sales as 0. Without enforcement, thousands of bad records could pollute the data warehouse, requiring a costly and urgent data cleanup project.