Serialization और Schemas

Bytes अंदर, अनुबंध ज़रूरी

Kafka bytes रखता है; producers और consumers तय करते हैं कि objects को bytes में कैसे बदला जाए। सादा JSON पढ़ने में आसान है पर लंबा है और कोई schema लागू नहीं होता। Avro, Protobuf और JSON Schema संक्षिप्त हैं और परिभाषित schema रखते हैं। Schema registry (जैसे Confluent Schema Registry या Apicurio) हर schema के versions रखती है, ऐसी IDs देती है जो records में जुड़ी होती हैं, और compatibility नियम लागू करती है (जैसे backward-compatible: नए readers पुराना डेटा पढ़ सकें) ताकि टीमें consumers तोड़े बिना fields जोड़ सकें। Compatibility सोच-समझकर चुनें और fields का नाम बदलने या हटाने की जगह defaults वाले वैकल्पिक fields जोड़कर schemas विकसित करें।

Backward-compatible बदलाव

Version 2 एक वैकल्पिक coupon field default के साथ जोड़ता है, इसलिए version 2 के consumers version 1 से लिखे records भी पढ़ सकते हैं। (Avro schema, उदाहरण।)

{
  "type": "record",
  "name": "OrderPlaced",
  "fields": [
    {"name": "order_id", "type": "string"},
    {"name": "amount",   "type": "double"},
    {"name": "coupon",   "type": ["null", "string"], "default": null}
  ]
}

किसी field का नाम नए अर्थ के साथ दोबारा उपयोग न करें

मौजूदा field का अर्थ बदलना चुपचाप consumers को तोड़ता है, भले types मेल खाते हों। इसके बजाय नया field जोड़ें और पुराने को धीरे-धीरे हटाएँ।

त्वरित जाँच: कौन-सा schema बदलाव आम तौर पर backward-compatible है?

• Field का type string से int बदलना
• अनिवार्य field का नाम बदलना
• Default के साथ वैकल्पिक field जोड़ना
• अनिवार्य field हटाना