Schema compatibility rules in Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this compatibility check?

Given a schema registry with BACKWARD compatibility mode, what will happen if you try to register this new schema?

{"type": "record", "name": "User", "fields": [{"name": "name", "type": "string"}, {"name": "age", "type": "int"}]}

Original schema was:

{"type": "record", "name": "User", "fields": [{"name": "name", "type": "string"}]}

A Registration succeeds because adding a field with a default value is backward compatible.

B Registration fails because removing fields is not allowed in backward compatibility.

C Registration fails because adding a new field without a default value breaks backward compatibility.

D Registration succeeds because adding any field is always compatible.

💡 Hint

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

Adding a new field without a default value breaks backward compatibility because old data won't have that field, causing read errors.

❓ Predict Output

intermediate

What error occurs when registering incompatible schema in FORWARD mode?

Original schema:

{"type": "record", "name": "Product", "fields": [{"name": "id", "type": "int"}, {"name": "price", "type": "float"}]}

New schema:

{"type": "record", "name": "Product", "fields": [{"name": "id", "type": "int"}]}

Compatibility mode: FORWARD

A Registration fails because removing a field breaks forward compatibility.

B Registration succeeds because forward compatibility ignores removed fields.

C Registration succeeds because removing a field is forward compatible.

D Registration fails because adding fields is not allowed in forward compatibility.

💡 Hint

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

Removing a field breaks forward compatibility because old readers expect that field but new data won't have it.

🔧 Debug

advanced

Identify the compatibility mode violation

Given the following original and new schemas, and the compatibility mode set to FULL, which change causes the registration to fail?

Original schema:
{"type": "record", "name": "Employee", "fields": [{"name": "id", "type": "int"}, {"name": "name", "type": "string"}]}

New schema:
{"type": "record", "name": "Employee", "fields": [{"name": "id", "type": "int"}, {"name": "fullName", "type": "string", "default": ""}]}

A Adding a new field with a default value is not allowed in full compatibility.

B Changing field name from 'name' to 'fullName' breaks full compatibility.

C Removing the 'name' field is allowed in full compatibility.

D Changing the record name breaks full compatibility.

💡 Hint

Full compatibility requires both backward and forward compatibility.

Renaming a field is not backward or forward compatible because readers expect the original field name.

🧠 Conceptual

advanced

Which compatibility mode allows adding optional fields with defaults?

Which Kafka schema compatibility mode permits adding new fields with default values without breaking compatibility?

A FORWARD compatibility

B NONE compatibility

C FULL compatibility

D BACKWARD compatibility

💡 Hint

Think about which mode ensures new schemas can read old data.

Backward compatibility allows adding new fields with defaults because old data can still be read by the new schema.

❓ Predict Output

expert

How many fields will be present after schema evolution in FULL compatibility?

Original schema:

{"type": "record", "name": "Order", "fields": [{"name": "orderId", "type": "int"}, {"name": "amount", "type": "float"}]}

New schema:

{"type": "record", "name": "Order", "fields": [{"name": "orderId", "type": "int"}, {"name": "amount", "type": "float"}, {"name": "discount", "type": "float", "default": 0.0}]}

Compatibility mode: FULL

After evolution, how many fields will the new schema have?

A 3 fields

B 1 field

C 2 fields

D 4 fields

💡 Hint

Adding a field with a default value is allowed in full compatibility.

The new schema adds one field with a default value, so total fields become 3.