# Serialization और Schemas — Apache Kafka: बुनियाद से Production तक Event Streaming

Source: https://www.geekswithgeeks.com/hi/kafka/kp-serialization-schemas

> Record format चुनें और schema registry से schema evolution सँभालें।

## 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, उदाहरण।)

```json
{
  "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 जोड़ें और पुराने को धीरे-धीरे हटाएँ।

**Quiz:** कौन-सा schema बदलाव आम तौर पर backward-compatible है?

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

*Answer:* Default के साथ वैकल्पिक field जोड़ना. Default वाला वैकल्पिक field नए readers को पुराने records सँभालने देता है।