Schema compatibility rules in Kafka - Step-by-Step Execution

Process Flow - Schema compatibility rules

Start with Existing Schema

↓

New Schema Submitted

↓

Check Compatibility Type

↓

BACKWARD

↓

Compare New Schema with Old Schema

↓

Is Compatibility Maintained?

↓

Accept New Schema

↓

End

The flow checks if a new schema is compatible with the existing one based on the chosen compatibility rule, then accepts or rejects it.

Execution Sample

Kafka

Existing schema: {"type":"record","fields":[{"name":"id","type":"int"}]}
New schema: {"type":"record","fields":[{"name":"id","type":"int"},{"name":"name","type":"string","default":""}]}
Compatibility: BACKWARD
Result: Accepted

This example shows adding a new optional field with a default value under backward compatibility, which is accepted.

Process Table

Step	Action	Compatibility Type	Check Description	Result
1	Start with existing schema	-	-	Ready for new schema
2	Submit new schema	-	-	New schema received
3	Check compatibility type	BACKWARD	New schema must read old data	Proceed to check
4	Compare schemas	BACKWARD	New schema adds field with default	Compatible
5	Decision	BACKWARD	Compatibility maintained	Accept new schema
6	End	-	-	Schema updated successfully

💡 New schema accepted because it is backward compatible with the existing schema.

Status Tracker

Variable	Start	After Step 2	After Step 4	Final
existing_schema	{"id": "int"}	{"id": "int"}	{"id": "int"}	{"id": "int"}
new_schema	N/A	{"id": "int", "name": "string" (default)}	{"id": "int", "name": "string" (default)}	{"id": "int", "name": "string" (default)}
compatibility_type	N/A	BACKWARD	BACKWARD	BACKWARD
compatibility_result	N/A	N/A	Compatible	Accepted

Key Moments - 3 Insights

Why is adding a new field with a default value backward compatible?

Because old data without the new field can still be read by the new schema using the default value, as shown in step 4 of the execution_table.

What happens if the new schema removes a field under backward compatibility?

It breaks backward compatibility because the new schema cannot read old data that contains the removed field, leading to rejection as per the compatibility check.

How does full compatibility differ from backward or forward?

Full compatibility requires both backward and forward compatibility, meaning new and old schemas can read each other's data, ensuring maximum safety.

Visual Quiz - 3 Questions

Look at the execution_table at step 4, what compatibility check is performed?

A Backward compatibility check

B Forward compatibility check

C Full compatibility check

D No compatibility check

💡 Hint

Refer to the 'Compatibility Type' column at step 4 in the execution_table.

At which step is the new schema accepted?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Check the 'Result' column for acceptance in the execution_table.

If the new schema removed a required field, what would change in the execution_table?

A Step 4 would show 'Compatible'

B Step 5 would show 'Reject new schema'

C Step 3 would change compatibility type

D Step 6 would be skipped

💡 Hint

Look at the 'Check Description' and 'Result' columns in steps 4 and 5.

Concept Snapshot

Schema compatibility rules ensure new schemas work with old data.
Backward: new schema reads old data.
Forward: old schema reads new data.
Full: both backward and forward.
Adding fields with defaults is backward compatible.
Removing fields breaks backward compatibility.

Full Transcript

Schema compatibility rules in Kafka control how new schemas relate to existing ones. When a new schema is submitted, the system checks compatibility based on the chosen rule: backward, forward, or full. Backward compatibility means the new schema can read data written with the old schema. Forward compatibility means the old schema can read data written with the new schema. Full compatibility requires both backward and forward compatibility. For example, adding a new field with a default value is backward compatible because old data without that field can still be read using the default. Removing a field breaks backward compatibility because the new schema cannot read old data containing that field. The process accepts or rejects the new schema accordingly.

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