Schema compatibility rules in Kafka - Mini Project: Build & Apply

Understanding Schema Compatibility Rules in Kafka

📖 Scenario: You are working with Apache Kafka and using Avro schemas to manage your data formats. You want to ensure that when you update your data schema, it remains compatible with previous versions so that your Kafka consumers do not break.

🎯 Goal: Build a simple example to understand how schema compatibility rules work in Kafka by defining schemas and checking compatibility.

📋 What You'll Learn

Create an initial Avro schema as a JSON string

Define a compatibility rule variable

Write a function to check if a new schema is compatible with the old schema based on the rule

Print the compatibility check result

💡 Why This Matters

🌍 Real World

In real Kafka projects, schema compatibility ensures that producers and consumers can evolve independently without breaking data processing.

💼 Career

Understanding schema compatibility is essential for data engineers and backend developers working with Kafka and schema registries to maintain reliable data pipelines.

1

Create the initial Avro schema

Create a variable called old_schema and assign it this exact JSON string representing an Avro schema: {"type": "record", "name": "User", "fields": [{"name": "name", "type": "string"}, {"name": "age", "type": "int"}]}

Kafka

# Create the initial Avro schema as a JSON string
# Your code here

Hint

Use a string variable to store the JSON schema exactly as shown.

2

Define the compatibility rule

Create a variable called compatibility_rule and set it to the string BACKWARD to represent the schema compatibility mode.

Kafka

old_schema = '{"type": "record", "name": "User", "fields": [{"name": "name", "type": "string"}, {"name": "age", "type": "int"}]}'
# Define the compatibility rule as 'BACKWARD'
# Your code here

Hint

Set the compatibility rule variable to the exact string 'BACKWARD'.

3

Write a function to check schema compatibility

Write a function called is_compatible that takes two parameters: old_schema and new_schema. Inside the function, return True if compatibility_rule is BACKWARD and the new schema adds a new optional field called email. Otherwise, return False. Use simple string checks to simulate compatibility.

Kafka

old_schema = '{"type": "record", "name": "User", "fields": [{"name": "name", "type": "string"}, {"name": "age", "type": "int"}]}'
compatibility_rule = "BACKWARD"

# Write the is_compatible function below
# Your code here

Hint

Check if the compatibility rule is 'BACKWARD' and if the new schema string contains the field 'email'.

4

Check and print schema compatibility

Create a variable called new_schema with this exact JSON string: {"type": "record", "name": "User", "fields": [{"name": "name", "type": "string"}, {"name": "age", "type": "int"}, {"name": "email", "type": ["null", "string"], "default": null}]}. Then print the result of calling is_compatible(old_schema, new_schema).

Kafka

old_schema = '{"type": "record", "name": "User", "fields": [{"name": "name", "type": "string"}, {"name": "age", "type": "int"}]}'
compatibility_rule = "BACKWARD"

def is_compatible(old_schema, new_schema):
    if compatibility_rule == "BACKWARD" and '"name": "email"' in new_schema:
        return True
    return False

# Create new_schema variable and print compatibility check
# Your code here

Hint

Use the exact new schema string and print the result of the compatibility function.

Practice

1. What does the BACKWARD compatibility rule in Kafka Schema Registry ensure?

easy

A. Both old and new schemas can read each other's data

B. Old schema can read data produced with the new schema

C. No compatibility checks are enforced

D. New schema can read data produced with the previous schema

Solution

1. Step 1: Understand BACKWARD compatibility meaning

   BACKWARD compatibility means new schema can read data written with the old schema.

2. Step 2: Compare options with definition

   New schema can read data produced with the previous schema matches this definition exactly, others describe different rules.

3. Final Answer:

   New schema can read data produced with the previous schema -> Option D

4. Quick Check:

   BACKWARD = New reads old [OK]

Hint: Backward means new schema reads old data [OK]

Common Mistakes:

• Confusing backward with forward compatibility
• Thinking backward means old reads new
• Assuming no compatibility checks

2. Which of the following is the correct way to set schema compatibility to FULL using Kafka Schema Registry REST API?

easy

A. POST /config -d '{"compatibilityLevel": "FULL"}'

B. PUT /config -d '{"compatibilityLevel": "FULL"}'

C. PUT /config -d '{"compatibility": "FULL"}'

D. GET /config -d '{"compatibility": "FULL"}'

Solution

1. Step 1: Identify correct HTTP method and endpoint

   Setting compatibility uses PUT on /config endpoint.

2. Step 2: Check correct JSON field name

   The field is "compatibilityLevel", not "compatibility".

3. Final Answer:

   PUT /config -d '{"compatibilityLevel": "FULL"}' -> Option B

4. Quick Check:

   PUT + compatibilityLevel = FULL [OK]

Hint: Use PUT and compatibilityLevel field [OK]

Common Mistakes:

• Using POST instead of PUT
• Using wrong JSON field name
• Using GET method to set config

3. Given the following schemas, which is the most restrictive compatibility rule that will allow the new schema to be registered without error?

Old schema: {"type": "record", "name": "User", "fields": [{"name": "name", "type": "string"}]}
New schema: {"type": "record", "name": "User", "fields": [{"name": "name", "type": "string"}, {"name": "age", "type": ["null", "int"], "default": null}]}

medium

A. FULL

B. FORWARD

C. NONE

D. BACKWARD

Solution

1. Step 1: Analyze schema change

   The new schema adds a field with a default value, which is backward and forward compatible.

2. Step 2: Determine compatibility rules allowing this

   FULL compatibility requires both backward and forward compatibility, which this change satisfies.

3. Final Answer:

   FULL -> Option A

4. Quick Check:

   Adding default field = FULL compatible [OK]

Hint: Adding default fields supports full compatibility [OK]

Common Mistakes:

• Thinking adding fields breaks backward compatibility
• Confusing NONE with allowing all changes
• Ignoring default values in new fields

4. You try to register a new schema that removes a required field from the old schema under BACKWARD compatibility. What is the likely result?

medium

A. Schema registration succeeds without errors

B. Schema registration succeeds but consumers break at runtime

C. Schema registration fails due to compatibility violation

D. Schema registration succeeds but producers reject data

Solution

1. Step 1: Understand backward compatibility rules

   Backward compatibility requires new schema to read old data, so removing required fields breaks this.

2. Step 2: Predict schema registry behavior

   Registry rejects schemas violating compatibility rules, so registration fails.

3. Final Answer:

   Schema registration fails due to compatibility violation -> Option C

4. Quick Check:

   Removing required field breaks backward = fail [OK]

Hint: Removing required fields breaks backward compatibility [OK]

Common Mistakes:

• Assuming registration always succeeds
• Confusing runtime errors with registration errors
• Thinking producers reject data on schema mismatch

5. You have a Kafka topic with schema compatibility set to FORWARD. You want to add a new optional field to the schema without breaking existing consumers. Which approach should you take?

hard

A. Add the new field with a default value or make it nullable

B. Remove an existing required field to simplify the schema

C. Add the new field without a default value

D. Change the type of an existing field to a different primitive type

Solution

1. Step 1: Understand FORWARD compatibility

   FORWARD compatibility means old schema can read data written with new schema.

2. Step 2: Determine safe schema changes

   Adding optional fields with defaults or nullable types preserves forward compatibility.

3. Step 3: Evaluate options

   Only Add the new field with a default value or make it nullable adds a field safely; others break compatibility or cause errors.

4. Final Answer:

   Add the new field with a default value or make it nullable -> Option A

5. Quick Check:

   Forward compatible additions need defaults or nullable [OK]

Hint: Add optional fields with defaults for forward compatibility [OK]

Common Mistakes:

• Adding required fields without defaults
• Removing fields under forward compatibility
• Changing field types without compatibility checks