Data format আর serialization — JSON, Protobuf, Avro আর schema evolution

১ · Serialization কী, আর নকশায় এর দাম কোথায়

একটি mobile banking সেবার (কাল্পনিক) গল্প দিয়ে শুরু করি। লেনদেন হলেই payment service একটি বার্তা পাঠায় notification service-কে, আর সেটি গ্রাহককে জানায় “আপনার অ্যাকাউন্টে টাকা জমা হয়েছে”। এক বিকেলে বার্তার amount field-টি টাকা থেকে পয়সায় বদলে নতুন সংস্করণ চালু হলো; deploy চলল দশ মিনিট ধরে, সার্ভার একটি একটি করে বদলাল। ওই দশ মিনিটে কিছু গ্রাহক পেলেন একশো গুণ বড় অঙ্কের বার্তা। Network ঠিক, database-ও ঠিক — গোলমাল একটিই: দুই সংস্করণের কোড একই byte-এর দুই রকম অর্থ করছিল। এই পর্বের বিষয় ঠিক এটাই।

প্রোগ্রাম চলার সময় ডেটা থাকে memory-তে, object আর pointer হয়ে। একটি Customer object-এর নাম হয়তো memory-র অন্য কোনো ঠিকানায় রাখা — সেই ঠিকানার অর্থ শুধু ওই process-এর ভেতরে। অন্য মেশিনে পাঠাতে বা disk-এ রাখতে হলে ডেটাকে একটি স্বয়ংসম্পূর্ণ byte-এর সারিতে বদলাতে হয়। একে বলে serialization (encoding বা marshalling নামেও চলে); উল্টো কাজটির নাম deserialization, যাকে decoding বা parsing-ও বলা হয়। Byte-গুলো কোন ক্রমে, কোন নিয়মে সাজানো — সেটাই data format, আর ডেটার কাঠামোর লিখিত চুক্তিকে বলে schema.

System design-এ serialization প্রায় প্রতিটি তীরের ভেতরে লুকিয়ে থাকে: API-র request ও response (পর্ব ৮, পর্ব ৯), message queue-র বার্তা (পর্ব ৩১), database-এর ভেতরের সারি (পর্ব ১৯), cache-এ রাখা মান (পর্ব ২৮), backup আর log ফাইল। Format বাছাইয়ের চারটি দাম:

২ · Text format — JSON, XML আর CSV

JSON (JavaScript Object Notation) আজকের web-এর সাধারণ ভাষা। এতে মাত্র ছয় রকম মান: object {}, array [], string, number, true/false আর null. একটি payment event দেখতে এমন:

{
  "eventId": "9007199254740993",
  "amountPaisa": 125050,
  "currency": "BDT",
  "note": "ঈদের বোনাস",
  "createdAt": "2026-10-28T14:05:00+06:00"
}

JSON-এর শক্তি তিনটি: মানুষ পড়তে পারে, প্রায় সব ভাষায় parser আছে, আর এটি self-describing — প্রতিটি মানের সাথে তার নাম (key) যায়, তাই schema ছাড়াও মোটামুটি বোঝা যায়। দুর্বলতাও স্পষ্ট: প্রতিটি record-এ একই key বারবার লেখা হয়, integer আর দশমিকের আলাদা type নেই, binary ডেটা বা তারিখের type নেই (তাই তারিখ যায় ISO 8601 string হিসেবে, সময়ের অঞ্চলসহ — বাংলাদেশে +06:00), comment লেখা যায় না, আর ডিফল্টভাবে কোনো schema নেই — কোন field বাধ্যতামূলক, কোনটির type কী, তা কোথাও লেখা থাকে না।

Schema যোগ করা — JSON Schema. JSON-এর schema-হীনতার একটি জনপ্রিয় সমাধান JSON Schema: আলাদা একটি JSON নথিতে লেখা থাকে কোন field আছে, type কী, কোনটি বাধ্যতামূলক। OpenAPI (পর্ব ৮) API-র request-response বর্ণনায় এরই একটি রূপ ব্যবহার করে। লেখার সময়ে সর্বশেষ বড় সংস্করণটি 2020-12 নামে পরিচিত:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["eventId", "amountPaisa"],
  "properties": {
    "eventId":     { "type": "string" },
    "amountPaisa": { "type": "integer", "minimum": 1 },
    "currency":    { "type": "string", "enum": ["BDT"] },
    "note":        { "type": "string", "maxLength": 140 }
  },
  "additionalProperties": true
}

শেষ লাইনটি খেয়াল করুন। additionalProperties false করলে schema-য় নেই এমন field এলেই যাচাই ব্যর্থ হয় — তখন নতুন সংস্করণ একটি field যোগ করলেই পুরোনো যাচাইকারী সব বার্তা প্রত্যাখ্যান করবে। কড়াকড়ি দেখতে নিরাপদ, কিন্তু অংশ ৭-এ দেখবেন এটি forward compatibility ভেঙে দেয়।

XML ট্যাগ দিয়ে ডেটা ঘিরে রাখে: <amount currency="BDT">125050</amount>. এতে attribute, namespace আর XSD নামের শক্তিশালী schema ভাষা আছে, কিন্তু দুটি ট্যাগে আকার বাড়ে, parsing-ও ভারী। নতুন web API-তে XML কম, তবে প্রতিষ্ঠানের তথ্য-বিনিময় আর আর্থিক বার্তায় এখনো চালু — আন্তর্জাতিক পেমেন্ট বার্তার ISO 20022 মান মূলত XML-ভিত্তিক; আপনার .docx ফাইলটিও আসলে zip করা কয়েকটি XML ফাইল।

CSV (comma-separated values) সবচেয়ে সরল: প্রথম লাইনে কলামের নাম, তারপর প্রতি লাইনে একটি সারি। লাখো সারির bulk export-import, spreadsheet আর data warehouse-এ তোলার জন্য চমৎকার। কিন্তু নিয়মের ঘাটতি অনেক:

account_no,name,city,amount_paisa
0012345678,Rahim,Dhaka,125050
0012345679,"Karim, Jr.",Khulna,99900

• মানের ভেতরে কমা থাকলে উদ্ধৃতিচিহ্ন লাগে ("Karim, Jr."); নিয়মটি RFC 4180 (২০০৫)-এ লেখা, কিন্তু বাস্তবে নানা রকম “dialect” চলে।
• কোনো type নেই — spreadsheet 0012345678-কে সংখ্যা ভেবে শুরুর শূন্যগুলো মুছে দেয়; শূন্য দিয়ে শুরু হওয়া মোবাইল নম্বরেরও একই দশা হয়।
• Encoding অস্পষ্ট — বাংলা লেখা থাকা UTF-8 CSV কিছু spreadsheet প্রোগ্রামে (অনেক সংস্করণে) ফাইলের শুরুতে একটি বিশেষ চিহ্ন, BOM, না থাকলে ভাঙা অক্ষরে দেখায়।
• নেস্টেড ডেটা (যেমন একাধিক tag) রাখার স্বাভাবিক উপায় নেই।

৩ · JSON-এর তিন ফাঁদ — বড় সংখ্যা, বাংলা লেখা আর binary ডেটা

ফাঁদ ১ — ২^৫৩-এর চেয়ে বড় integer. JSON-এর নিয়ম সংখ্যার আকার সীমিত করে না, কিন্তু JavaScript (আর আরও অনেক parser) প্রতিটি সংখ্যা রাখে IEEE 754-এর ৬৪-bit double হিসেবে। Double-এ আছে ১টি sign bit, ১১টি exponent bit আর ৫২টি fraction bit; সামনে একটি লুকানো ১ ধরে মোট ৫৩ bit-এর নির্ভুলতা। তাই ২^৫৩ পর্যন্ত প্রতিটি পূর্ণসংখ্যা হুবহু রাখা যায়। কিন্তু ২^৫৩ থেকে ২^৫৪-এর মধ্যে পাশাপাশি দুটি double-এর ফারাক ২ — বিজোড় সংখ্যাগুলোর জায়গাই নেই। তাই ২^৫৩ + ১ গোল হয়ে ২^৫৩ হয়ে যায়, আর কোনো error-ও আসে না। নিরাপদ সীমা Number.MAX_SAFE_INTEGER = ৯,০০৭,১৯৯,২৫৪,৭৪০,৯৯১ = ২^৫৩ − ১. বিস্তারিত দেখুন Computer Architecture-এর floating point পর্বে আর JavaScript-এর number পর্বে।

বড় সিস্টেমের ID প্রায়ই ৬৪-bit — যেমন সময়ের ক্রমে সাজানো, ১৯ অঙ্কের Snowflake-ধাঁচের ID (পর্ব ২৩)। Browser-এর JavaScript পড়ার সময় শেষের অঙ্কগুলো বদলে ফেলে, তারপর ভুল ID দিয়ে পরের অনুরোধ যায় — অন্য কারও অর্ডার খোলে বা “পাওয়া যায়নি” আসে। সমাধান সরল: বড় ID সবসময় string হিসেবে পাঠান। Protobuf-এর অফিশিয়াল JSON রূপও int64-কে string হিসেবে লেখে, আর Twitter (এখন X)-এর প্রকাশিত API ডকুমেন্টেশনে ঠিক এই কারণেই সংখ্যার পাশাপাশি id_str নামে string রূপ দেওয়া হতো। টাকার অঙ্কে আরেকটি নিয়ম: কখনো দশমিক double নয় — ৳১,২৫০.৫০-কে পূর্ণসংখ্যা পয়সায় (125050) বা দশমিক string-এ রাখুন, কারণ double-এ 0.1 + 0.2 হয় 0.30000000000000004.

ফাঁদ ২ — বাংলা লেখার byte. UTF-8 প্রতিটি Unicode code point-কে ১ থেকে ৪ byte-এ লেখে: ASCII (ইংরেজি অক্ষর, অঙ্ক) ১ byte, U+0080–U+07FF ২ byte, U+0800–U+FFFF ৩ byte, তার ওপরে ৪ byte. বাংলা লিপির Unicode block U+0980–U+09FF, অর্থাৎ প্রতিটি বাংলা code point UTF-8-এ ৩ byte নেয়। “Dhaka” ৫ byte, কিন্তু “ঢাকা” (ঢ, া, ক, া — চারটি code point) ১২ byte. আবার চোখে একটি অক্ষর মানেই একটি code point নয়: “ক্ষ” = ক + ্ + ষ, তিনটি code point, ৯ byte. চোখে দেখা এই এককটিকে বলে grapheme cluster. তাই “নাম সর্বোচ্চ ৫০ অক্ষর” লেখার আগে ঠিক করুন — byte, code point, JavaScript-এর UTF-16 একক, নাকি চোখে দেখা অক্ষর? Database, index আর SMS-এর সীমা আলাদা এককে মাপা হতে পারে; যেমন SMS-এ বাংলা সাধারণত UCS-2-এ যায়, এক বার্তায় ৭০টি code point (ইংরেজিতে ১৬০টি অক্ষর)।

আরেকটি লুকানো খরচ: কিছু JSON লাইব্রেরি ডিফল্টভাবে ASCII-র বাইরের প্রতিটি অক্ষরকে \u09a2 ধাঁচের escape-এ লেখে (যেমন Python-এর json.dumps, যার ensure_ascii ডিফল্টভাবে চালু)। তখন প্রতিটি বাংলা code point ৩-এর বদলে ৬ byte নেয়: {"city": "ঢাকা"} UTF-8-এ ২৪ byte, escape-সহ ৩৬ byte. ভুল encoding ধরে পড়লে আরেক বিপদ — “ঢাকা”-র UTF-8 byte-কে Windows-1252 ভেবে পড়লে দেখায় ঢাকা; এই ভাঙা লেখাকে বলে mojibake. Unicode-এর গভীরে যেতে দেখুন ডেটার বিট-রূপ পর্ব আর বাংলা টাইপিং আর Unicode পর্ব।

ফাঁদ ৩ — binary ডেটা। JSON-এ byte রাখার type নেই, তাই ছবি বা ফাইল পাঠাতে হয় Base64-এ: প্রতি ৩ byte (২৪ bit) ভেঙে ৪টি ৬-bit টুকরো, প্রতিটি টুকরো ৬৪টি ছাপার যোগ্য অক্ষরের একটি (A–Z, a–z, 0–9, +, /)। ফলে n byte-এর Base64 দৈর্ঘ্য ৪⌈n/৩⌉ — শেষে দরকারমতো = দিয়ে ভরাট করা হয় (RFC 4648 অনুযায়ী)। বড় ডেটায় অনুপাত ৪/৩, অর্থাৎ প্রায় ৩৩.৩% বাড়তি:

Base64 কোনো encryption নয় — যে কেউ মুহূর্তে উল্টে পড়তে পারেন; গোপন তথ্য Base64 করে “লুকানো” যায় না। বড় ফাইল JSON-এ না ভরে object storage-এ (পর্ব ২৬) তুলে শুধু তার ঠিকানা পাঠানোই সাধারণত ভালো নকশা। নিচের কোড প্রথম দুটি ফাঁদ নিজে দেখায়:

// (1) How many bytes does text take in UTF-8?  (2) What does JSON do to a big integer ID?
const utf8 = new TextEncoder();
const esc = s => s.replace(/[^\x00-\x7f]/g, c => "\\u" + c.charCodeAt(0).toString(16).padStart(4, "0"));
console.log("code points | UTF-8 bytes | bytes as \\uXXXX | text");
for (const s of ["Dhaka", "ঢাকা", "আমার সোনার বাংলা", "ক্ষ"]) {
  const cp = [...s].length, bytes = utf8.encode(s).length;
  console.log(String(cp).padStart(11) + " | " + String(bytes).padStart(11) + " | " + String(esc(s).length).padStart(15) + " | " + s);
}
console.log("ঢাকা =", [...("ঢাকা")].map(c => "U+" + c.codePointAt(0).toString(16).toUpperCase().padStart(4, "0")).join(" "));
console.log("ঢ in UTF-8 =", [...utf8.encode("ঢ")].map(b => b.toString(16)).join(" "));

console.log("\nNumber.MAX_SAFE_INTEGER =", Number.MAX_SAFE_INTEGER, "= 2^53 - 1");
console.log("2^53 + 1 === 2^53 ?", 2 ** 53 + 1 === 2 ** 53);
const wire = '{"orderId": 9007199254740993, "orderIdStr": "9007199254740993"}';
const o = JSON.parse(wire);
console.log("sent 9007199254740993 as number ->", o.orderId);
console.log("sent it as a string             ->", o.orderIdStr, "| next id:", BigInt(o.orderIdStr) + 1n);
const snowflake = '{"id": 1541815603606036481}';      // a 64-bit, Snowflake-style ID
console.log("64-bit ID as number ->", JSON.parse(snowflake).id);

code points | UTF-8 bytes | bytes as \uXXXX | text
          5 |           5 |               5 | Dhaka
          4 |          12 |              24 | ঢাকা
         16 |          44 |              86 | আমার সোনার বাংলা
          3 |           9 |              18 | ক্ষ
ঢাকা = U+09A2 U+09BE U+0995 U+09BE
ঢ in UTF-8 = e0 a6 a2

Number.MAX_SAFE_INTEGER = 9007199254740991 = 2^53 - 1
2^53 + 1 === 2^53 ? true
sent 9007199254740993 as number -> 9007199254740992
sent it as a string             -> 9007199254740993 | next id: 9007199254740994n
64-bit ID as number -> 1541815603606036500

৪ · Protocol Buffers — field number, wire type আর varint

Protocol Buffers (সংক্ষেপে Protobuf) একটি binary format, যার schema লেখা হয় একটি IDL-এ (interface definition language, অর্থাৎ interface বর্ণনার ভাষা)। Google-এর ভেতরে বহু বছর ব্যবহারের পর ২০০৮ সালে এটি open source হয়; বর্তমান রূপ proto3 আসে ২০১৬ সালে। Schema থেকে protoc compiler নানা ভাষার কোড বানায়। gRPC-তে Protobuf কীভাবে API-র চুক্তি হয় — service, method, streaming — তা দেখেছেন পর্ব ৯-এ; এখানে আমরা নামব byte-এর স্তরে:

syntax = "proto3";

message Customer {
  int64  id            = 1;
  string name          = 2;
  repeated string tags = 3;
  optional string city = 4;   // v2-তে যোগ হয়েছে
}

প্রতিটি field-এর ডান পাশের সংখ্যাটি তার field number. Byte-এ নাম যায় না, যায় এই সংখ্যা — তাই নাম বদলালেও binary ডেটা ভাঙে না, কিন্তু সংখ্যা বদলালে ভাঙে। প্রতিটি field-এর আগে বসে একটি key (tag):

Wire type জানায় পরের মানটি কত লম্বা, যাতে schema না জানলেও parser field-টি ডিঙিয়ে যেতে পারে:

৩ আর ৪ নম্বর wire type পুরোনো “group”-এর জন্য ছিল, এখন সেগুলো বাতিল (deprecated) বলে গণ্য। I64 আর I32-এর মান little-endian ক্রমে বসে — কম গুরুত্বপূর্ণ byte আগে (byte-ক্রমের বিস্তারিত ডেটার বিট-রূপ পর্বে)।

Varint হলো ছোট সংখ্যাকে কম byte-এ লেখার কৌশল: প্রতি byte-এ ৭ bit মান, আর সবচেয়ে উঁচু bit-টি “continuation bit” — ১ মানে “আরও byte আসছে”, ০ মানে “শেষ”। কম গুরুত্বপূর্ণ ৭-bit দল আগে যায়। ফলে ০–১২৭ এক byte, ১২৮–১৬,৩৮৩ দুই byte, আর ৩২-bit-এর সবচেয়ে বড় মান পাঁচ byte. Key-ও varint, তাই field number ১–১৫ এক byte-এর key পায় — ঘনঘন ব্যবহৃত field-এর জন্য এগুলো রেখে দেওয়া ভালো অভ্যাস। এবার একটি field হাতে encode করি:

ঋণাত্মক সংখ্যা আর ZigZag. int32 বা int64 field-এ −১ লিখলে two's complement-এ সব bit ১ হয়, তাই varint-এ লাগে পুরো ১০ byte. ঋণাত্মক মান বেশি থাকলে sint32/sint64 ব্যবহার করুন — এরা ZigZag encoding করে: ০ → ০, −১ → ১, ১ → ২, −২ → ৩, অর্থাৎ ছোট মাত্রার ঋণাত্মক সংখ্যাও ছোট varint পায়; −১ লিখতে লাগে মাত্র এক byte, 01. Avro সব integer-এ এই কৌশলই ব্যবহার করে।

String আর repeated. String, bytes আর nested message যায় LEN হিসেবে: key, দৈর্ঘ্যের varint, তারপর byte. name = "Rahim" → 12 05 52 61 68 69 6d (key ২ × ৮ + ২ = ১৮ = 0x12, দৈর্ঘ্য ৫)। Repeated string-এর প্রতিটি উপাদান নিজের key নিয়ে যায়; repeated সংখ্যা proto3-এ ডিফল্টভাবে “packed” — একটি key, মোট দৈর্ঘ্য, তারপর পরপর varint.

Optional আর default. proto3-এ শূন্য মান (০, খালি string, false) byte-এ লেখাই হয় না, আর অনুপস্থিত field শূন্য ধরা হয় — তাই “ব্যালান্স ০” আর “ব্যালান্স জানানো হয়নি” আলাদা করা যায় না। পার্থক্য দরকার হলে optional লিখুন; proto3-এ এটি ২০২০–২১ সালের দিকে আবার যোগ হয়েছে।

Unknown field. পুরোনো reader অচেনা field number পেলে wire type দেখে বোঝে কত byte ডিঙাতে হবে, আর পরের field-এ চলে যায়। proto3 প্রথমে এমন field ফেলে দিত; সংস্করণ ৩.৫ (২০১৭ সালের দিকে) থেকে আবার proto2-র মতো রেখে দেয়, যাতে message আবার লেখার সময় অচেনা field-টিও অক্ষত থাকে। নিচের ছোট encoder-decoder এর সবটা দেখায়:

// A minimal Protobuf wire-format encoder/decoder: varints, field keys, strings.
function varint(n) {                        // non-negative integers only
  const out = [];
  do { let b = n % 128; n = Math.floor(n / 128); if (n > 0) b += 128; out.push(b); } while (n > 0);
  return out;
}
const utf8 = new TextEncoder(), text = new TextDecoder();
const key = (field, wire) => varint(field * 8 + wire);       // tag = (field << 3) | wire type
const vInt = (f, n) => [...key(f, 0), ...varint(n)];         // wire type 0 = VARINT
const vStr = (f, s) => { const b = [...utf8.encode(s)]; return [...key(f, 2), ...varint(b.length), ...b]; }; // 2 = LEN
const hex = a => a.map(b => b.toString(16).padStart(2, "0")).join(" ");

function decode(bytes, known) {             // known: field number -> name, from the READER's schema
  let i = 0; const msg = {}, unknown = [];
  const rv = () => { let n = 0, mul = 1, b; do { b = bytes[i++]; n += (b % 128) * mul; mul *= 128; } while (b >= 128); return n; };
  while (i < bytes.length) {
    const start = i, k = rv(), field = Math.floor(k / 8), wire = k % 8; let val;
    if (wire === 0) val = rv();
    else if (wire === 2) { const len = rv(); val = text.decode(new Uint8Array(bytes.slice(i, i + len))); i += len; }
    else throw new Error("wire type " + wire + " is not handled in this demo");
    const name = known[field];                                        // unknown field: skip, keep raw bytes
    if (!name) { unknown.push(hex(bytes.slice(start, i))); continue; }
    if (name === "tags") (msg.tags = msg.tags || []).push(val); else msg[name] = val;
  }
  return { msg, unknown };
}
// v1 schema: 1 = id (int64), 2 = name (string), 3 = tags (repeated string)
const v1 = [...vInt(1, 150), ...vStr(2, "Rahim"), ...vStr(3, "vip"), ...vStr(3, "new")];
console.log("field 1 = 150 ->", hex(vInt(1, 150)));
console.log("v1 message (" + v1.length + " bytes):", hex(v1));
const v1Fields = { 1: "id", 2: "name", 3: "tags" }; console.log("v1 reader, v1 data:", JSON.stringify(decode(v1, v1Fields).msg));
const v2 = [...v1, ...vStr(4, "Dhaka")];    // v2 adds 4 = city (string)
const r = decode(v2, v1Fields);
console.log("v2 message (" + v2.length + " bytes) ends with:", hex(v2.slice(-7)));
console.log("v1 reader, v2 data:", JSON.stringify(r.msg), "| unknown kept:", r.unknown.join(", "));

field 1 = 150 -> 08 96 01
v1 message (20 bytes): 08 96 01 12 05 52 61 68 69 6d 1a 03 76 69 70 1a 03 6e 65 77
v1 reader, v1 data: {"id":150,"name":"Rahim","tags":["vip","new"]}
v2 message (27 bytes) ends with: 22 05 44 68 61 6b 61
v1 reader, v2 data: {"id":150,"name":"Rahim","tags":["vip","new"]} | unknown kept: 22 05 44 68 61 6b 61

৫ · Avro — tag ছাড়া byte, writer আর reader-এর schema

Apache Avro এসেছে ২০০৯ সালের দিকে Hadoop-এর জগত থেকে (Doug Cutting-এর হাতে)। এর schema লেখা হয় JSON-এ, আর binary byte-এ কোনো field number বা নাম থাকে না — field-গুলোর মান schema-র ক্রমে পরপর বসে যায়:

{"type": "record", "name": "Customer", "fields": [
  {"name": "id",   "type": "int"},
  {"name": "name", "type": "string"},
  {"name": "city", "type": "string"}
]}

Record {id: 150, name: "Rahim", city: "Dhaka"} Avro-তে হয়: id-র ZigZag মান ৩০০ → ac 02; name-এর দৈর্ঘ্য ৫, ZigZag-এ ১০ → 0a, তারপর ৫ byte; city-ও তেমনি 0a + ৫ byte. মোট ১৪ byte; একই তিনটি field Protobuf-এ ১৭ byte (৩ + ৭ + ৭)। কিন্তু দাম আছে: ac 02 0a 52 … দেখে বোঝার উপায় নেই কোথায় একটি field শেষ, কোথায় আরেকটি শুরু। ঠিক যে schema দিয়ে লেখা হয়েছিল, সেই writer schema ছাড়া Avro byte পড়া যায় না। Writer schema আসে তিন জায়গা থেকে: বড় ফাইলের (Avro object container file) শুরুতে একবার লেখা থাকে, তারপর লাখো record; message system-এ প্রতিটি বার্তায় শুধু একটি ছোট schema ID, আর schema থাকে registry-তে (অংশ ৮); আর RPC-তে সংযোগের শুরুতে দুই পক্ষ schema বিনিময় করে।

Avro-র আসল জাদু schema resolution: reader নিজের schema (reader schema) আর লেখকের schema (writer schema) পাশাপাশি রেখে field নাম ধরে মেলায়। নিয়মগুলো:

• দুই পাশে একই নামের field — মান পড়া হয়; type আলাদা হলে শুধু অনুমোদিত “promotion” চলে: int → long → float → double, আর string ↔ bytes.
• Writer-এ আছে, reader-এ নেই — byte পড়ে বাদ দেওয়া হয় (পড়তেই হয়, নইলে পরের field কোথায় শুরু জানা যায় না)।
• Reader-এ আছে, writer-এ নেই — reader schema-র default বসে; default না থাকলে error.
• নাম বদল — reader schema-য় aliases দিলে পুরোনো নামের সাথে মেলে; alias ছাড়া নাম বদল মানে “একটি field মুছে আরেকটি যোগ”।
• Optional field — union দিয়ে: {"name": "phone", "type": ["null", "string"], "default": null}; default-কে union-এর প্রথম type-এর হতে হয়।

কখন Avro, কখন Protobuf? Avro-তে field number সামলাতে হয় না, তাই schema স্বয়ংক্রিয়ভাবে বানানো সহজ — যেমন database টেবিলের প্রতিদিনের dump থেকে; কলাম যোগ হলে নতুন schema, আর নাম ধরে resolution বাকিটা সামলায়। বড় ফাইলে schema একবারই থাকে, তাই data pipeline আর data lake-এ Avro জনপ্রিয়। হাতে লেখা, দীর্ঘস্থায়ী service API-তে Protobuf বেশি দেখা যায়। দুটির চিন্তা এক: schema আছে বলেই byte ছোট, আর schema-র নিয়ম মানলেই বিবর্তন নিরাপদ।

৬ · আরও কয়েকটি format, একই record-এর পাঁচ রকম আকার, আর compression

MessagePack (২০০৮ সালের দিকে) আর CBOR (RFC 7049, ২০১৩; হালনাগাদ RFC 8949, ২০২০) হলো “binary JSON” — একই কাঠামো, কিন্তু ছোট সংখ্যা এক byte-এ, দৈর্ঘ্য সামনে লেখা, আর আলাদা bytes type. Schema লাগে না, তাই key-এর নাম প্রতিটি record-এ যায়। CBOR ছোট IoT যন্ত্রে আর WebAuthn-এর মতো নিরাপত্তা-মানে ব্যবহৃত হয়। Apache Thrift Facebook-এ তৈরি হয়ে ২০০৭ সালে open source হয়; এটিও IDL-ভিত্তিক, field-এ সংখ্যাযুক্ত ID, আর কাজের ধরনে Protobuf-এর কাছাকাছি — সাথে নিজস্ব RPC কাঠামোও আছে।

এবার মাপজোখ। একটি গ্রাহকের record — id, নাম, শহর, দুটি tag, loyalty point — পাঁচভাবে লিখে byte গুনি। Encoder-গুলো আমাদের নিজের ছোট কোড, তাই আকার নির্ভরযোগ্য; গতি এখানে মাপা হচ্ছে না।

// One record, five encodings: how many bytes does each one put on the wire?
const utf8 = new TextEncoder();
const varint = n => { const o = []; do { let b = n % 128; n = Math.floor(n / 128); if (n) b += 128; o.push(b); } while (n); return o; };
const zigzag = n => (n >= 0 ? 2 * n : -2 * n - 1);           // Avro writes ints as zigzag varints
const str = s => { const b = [...utf8.encode(s)]; return [b.length, b]; };

const rec = { customerId: 150, customerName: "Rahim", homeCity: "Dhaka", tags: ["vip", "new"], loyaltyPoints: 2500 };

const jsonLong = JSON.stringify(rec);
const jsonShort = JSON.stringify({ i: rec.customerId, n: rec.customerName, c: rec.homeCity, t: rec.tags, p: rec.loyaltyPoints });

// Protobuf-style: every field carries a key (field number + wire type)
const pInt = (f, n) => [...varint(f * 8 + 0), ...varint(n)];
const pStr = (f, s) => { const [len, b] = str(s); return [...varint(f * 8 + 2), ...varint(len), ...b]; };
const proto = [...pInt(1, rec.customerId), ...pStr(2, rec.customerName), ...pStr(3, rec.homeCity),
               ...rec.tags.flatMap(t => pStr(4, t)), ...pInt(5, rec.loyaltyPoints)];

// Avro-style: no keys at all; fields in schema order, the reader must have the schema
const aStr = s => { const [len, b] = str(s); return [...varint(zigzag(len)), ...b]; };
const avro = [...varint(zigzag(rec.customerId)), ...aStr(rec.customerName), ...aStr(rec.homeCity),
              ...varint(zigzag(rec.tags.length)), ...rec.tags.flatMap(aStr), 0, ...varint(zigzag(rec.loyaltyPoints))];

const b64 = btoa(String.fromCharCode(...proto));            // binary inside a JSON/text field
const rows = [["JSON, long keys", utf8.encode(jsonLong).length], ["JSON, short keys", utf8.encode(jsonShort).length],
              ["Protobuf-style", proto.length], ["Avro-style", avro.length], ["Base64(Protobuf)", b64.length]];
const base = rows[0][1];
console.log("format".padEnd(18) + "bytes  vs JSON");
for (const [name, n] of rows) console.log(name.padEnd(18) + String(n).padStart(5) + "  " + (n / base * 100).toFixed(0).padStart(4) + "%");
console.log("Base64 / binary = " + b64.length + " / " + proto.length + " = " + (b64.length / proto.length).toFixed(3));
const perDay = 1e8;                                          // assume 10 crore events a day
console.log("10^8 events/day: JSON " + (base * perDay / 1e9).toFixed(1) + " GB, Protobuf " + (proto.length * perDay / 1e9).toFixed(1) + " GB");

format            bytes  vs JSON
JSON, long keys     102   100%
JSON, short keys     60    59%
Protobuf-style       30    29%
Avro-style           26    25%
Base64(Protobuf)     40    39%
Base64 / binary = 40 / 30 = 1.333
10^8 events/day: JSON 10.2 GB, Protobuf 3.0 GB

গতির কথা সাবধানে। Binary format সাধারণত দ্রুত decode হয় — text থেকে সংখ্যা বানানো বা key-এর নাম মেলানো লাগে না। কিন্তু গতি নির্ভর করে লাইব্রেরি, ভাষা আর ডেটার ধরনের ওপর; ভালো JSON parser অনেক binary লাইব্রেরির চেয়েও দ্রুত হতে পারে। লাইব্রেরির ওয়েবসাইটের benchmark আপনার ডেটা নয় — নিজের আসল payload দিয়ে মাপুন, আর throughput-এর সাথে p99 latency-ও দেখুন।

Compression — কখন লাভ, কখন ক্ষতি

Compression পুনরাবৃত্তি খুঁজে ছোট করে। পরিচিত তিনটি: gzip (DEFLATE-ভিত্তিক, RFC 1952, ১৯৯৬), Google-এর brotli (২০১৫; RFC 7932) আর zstd (২০১৬; RFC 8878), যা Facebook-এ Yann Collet-এর তৈরি। HTTP-তে browser Accept-Encoding header-এ জানায় কোনটি বোঝে, আর সার্ভার Content-Encoding-এ জানায় কোনটি দিল (HTTP পর্ব দেখুন)। আমাদের Node.js-এ (ডিফল্ট level) করা একটি ছোট পরীক্ষা:

• উপরের একটিমাত্র ১০২ byte-এর JSON record gzip করলে হলো ১১২ byte — আকার বাড়ল! gzip-এর নিজস্ব header আর trailer-ই ১৮ byte, আর এত ছোট লেখায় পুনরাবৃত্তি প্রায় নেই।
• একই ধাঁচের ১,০০০টি record-এর JSON array (১,০৩,১৫১ byte) gzip-এ ৫,৮২৮ আর brotli-তে ২,৫২৫ byte. তবে এই কৃত্রিম ডেটা খুবই একঘেয়ে; আসল ডেটায় অনুপাত সাধারণত এত ভালো হয় না।

তাই নিয়ম: বড়, পুনরাবৃত্তিময় payload-এ (key-ভরা JSON array, log) compression দারুণ; এক-একটি ছোট বার্তায় নয় — Kafka-র মতো সিস্টেম তাই পুরো batch একসাথে compress করে। আগেই compress করা (JPEG, MP4) বা encrypted ডেটা প্রায় ছোট হয় না। খরচ CPU-তে, দুই পাশেই, উঁচু level-এ আরও বেশি; সাধারণত decompress অনেক দ্রুত। ধীর mobile network-এ CPU খরচ করে byte বাঁচানো লাভজনক, data center-এর দ্রুত network-এ সবসময় নয় — মেপে দেখুন।

৭ · Schema evolution — backward, forward আর full compatibility

কাঠামো বদলাবেই — নতুন field আসবে, পুরোনো field অপ্রয়োজনীয় হবে। নিরাপদে বদলানোর বিদ্যাকে বলে schema evolution. এর দুটি দিক, আর নাম দুটি গুলিয়ে ফেলা খুব সাধারণ ভুল:

Backward তুলনামূলক সহজ — নতুন কোড লেখার সময় আপনি পুরোনো format জানেন। Forward কঠিন — পুরোনো কোডকে আগে থেকেই ভবিষ্যতের অচেনা ডেটা সহ্য করার মতো করে লিখতে হয় (অচেনা field ডিঙানো, রেখে দেওয়া)। একটি API-তে দুটোই একসাথে লাগে: নতুন সার্ভার পুরোনো app-এর request পড়ে — এটি backward; আর পুরোনো app নতুন সার্ভারের response পড়ে — এটি forward.

কেন দুই দিকই দরকার, তা সবচেয়ে ভালো বোঝা যায় rolling deployment-এ: সব সার্ভার একসাথে বন্ধ না করে একটি একটি করে নতুন সংস্করণে বদলানো, যাতে সেবা চালু থাকে (canary release-এও একই অবস্থা — কিছু সার্ভারে নতুন সংস্করণ; বিস্তারিত পর্ব ৫৩-এ)। নিচে চারটি সার্ভার, একটি shared database, আর v2-তে যোগ হলো field ৪ city:

কোন পরিবর্তন নিরাপদ, কোনটি ভাঙে

reserved শব্দটি Protobuf-এর পাহারাদার: মুছে ফেলা field-এর number আর নাম তালিকায় রাখলে কেউ ভুল করে আবার ব্যবহার করতে চাইলে protoc compile করতেই রাজি হয় না।

message Customer {
  reserved 3, 9 to 11;   // এই number-গুলো আর কাউকে দেওয়া যাবে না
  reserved "tags";       // নামটিও না, যাতে JSON রূপে বিভ্রান্তি না হয়
  int64  id   = 1;
  string name = 2;
}

নিয়মগুলো যন্ত্রে বসানো যায়। নিচের checker পুরোনো আর নতুন field-তালিকা (number, নাম, type, required কি না, default) নিয়ে দুই দিকে পড়ার চেষ্টা করে, আর কারণসহ রায় দেয়। নিয়মগুলো সরলীকৃত, Protobuf-ধাঁচের — field মেলানো হয় number ধরে:

// Schema-evolution checker (simplified Protobuf-style rules: fields are matched by NUMBER).
// BACKWARD = new code reads OLD data.   FORWARD = old code reads NEW data.
const F = (num, name, type, req = false, def = null) => ({ num, name, type, req, def });
function canRead(reader, writer) {            // can code with schema `reader` read bytes written with `writer`?
  const bad = [], ok = [];
  for (const r of reader) {
    const w = writer.find(x => x.num === r.num);
    if (!w) { if (r.req) bad.push(`#${r.num} ${r.name} is required but absent`); else ok.push(`#${r.num} absent -> default ${JSON.stringify(r.def)}`); continue; }
    if (w.type !== r.type) bad.push(`#${r.num} written as ${w.type}, read as ${r.type}`);
    else if (r.req && !w.req) bad.push(`#${r.num} ${r.name} is required here but was optional for the writer`);
    else if (w.name !== r.name) ok.push(`#${r.num} renamed ${w.name} -> ${r.name} (binary fine, JSON breaks)`);
  }
  for (const w of writer) if (!reader.some(r => r.num === w.num)) ok.push(`unknown #${w.num} skipped`);
  return { bad, ok };
}
function check(title, oldS, newS) {
  const b = canRead(newS, oldS), f = canRead(oldS, newS);
  const line = x => (x.bad.length ? "NO  " + x.bad.join("; ") : "yes " + (x.ok.join("; ") || "no conflict"));
  const verdict = b.bad.length ? (f.bad.length ? "BREAKING" : "FORWARD only") : (f.bad.length ? "BACKWARD only" : "FULL");
  console.log(title + "\n  backward: " + line(b) + "\n  forward:  " + line(f) + "\n  => " + verdict);
}
const v1 = [F(1, "id", "int64", true), F(2, "name", "string", false, ""), F(3, "tags", "string[]", false, [])];
check("A. add optional #4 city", v1, [...v1, F(4, "city", "string", false, "")]);
check("B. add required #5 phone", v1, [...v1, F(5, "phone", "string", true)]);
check("C. delete optional #3 tags", v1, v1.slice(0, 2));
check("D. delete required #1 id", v1, v1.slice(1));
check("E. reuse #3 for phone:string", v1, [...v1.slice(0, 2), F(3, "phone", "string")]);
check("F. rename #2 name -> fullName", v1, [v1[0], F(2, "fullName", "string", false, ""), v1[2]]);

A. add optional #4 city
  backward: yes #4 absent -> default ""
  forward:  yes unknown #4 skipped
  => FULL
B. add required #5 phone
  backward: NO  #5 phone is required but absent
  forward:  yes unknown #5 skipped
  => FORWARD only
C. delete optional #3 tags
  backward: yes unknown #3 skipped
  forward:  yes #3 absent -> default []
  => FULL
D. delete required #1 id
  backward: yes unknown #1 skipped
  forward:  NO  #1 id is required but absent
  => BACKWARD only
E. reuse #3 for phone:string
  backward: NO  #3 written as string[], read as string
  forward:  NO  #3 written as string, read as string[]
  => BREAKING
F. rename #2 name -> fullName
  backward: yes #2 renamed name -> fullName (binary fine, JSON breaks)
  forward:  yes #2 renamed fullName -> name (binary fine, JSON breaks)
  => FULL

৮ · বাস্তবে compatibility — schema registry, API version আর database migration

বড় প্রতিষ্ঠানে শত শত সার্ভিস একে অপরকে বার্তা পাঠায়। “সবাই নিয়ম মেনে চলবে” আশা করে বসে থাকলে একদিন কেউ ভুলবেই। তাই নিয়মটি পাহারা দেয় একটি কেন্দ্রীয় schema registry. নিচের ছবিতে একটি producer (v2) বার্তা পাঠাচ্ছে, আর পড়ছে এখনো v1-এ থাকা একটি consumer:

প্রবাহটি ধাপে ধাপে: (১) producer নতুন schema নিবন্ধন করতে চায়; registry একটি “subject”-এর (যেমন orders) আগের সংস্করণের সাথে নির্ধারিত নিয়মে মিলিয়ে দেখে, না মিললে প্রত্যাখ্যান করে। (২) মিললে একটি ছোট সংখ্যার ID দেয়। (৩) প্রতিটি বার্তায় পুরো schema নয়, শুধু এই ID যায় — Confluent-এর ডকুমেন্টেশনে বর্ণিত format অনুযায়ী শুরুতে একটি magic byte (০) আর চার byte-এর ID — big-endian ক্রমে, তাই ৪২ দেখায় 00 00 00 2a — অর্থাৎ বার্তাপ্রতি মাত্র ৫ byte বাড়তি। (৪–৬) consumer ID দিয়ে writer schema এনে cache করে, আর নিজের reader schema-র সাথে মিলিয়ে পড়ে — ঠিক অংশ ৫-এর resolution. পরিচিত উদাহরণ Confluent-এর Schema Registry, যা সংস্করণভেদে Avro ছাড়াও Protobuf আর JSON Schema সমর্থন করে।

Compatibility mode আর deploy-এর ক্রম। Confluent-ধাঁচের registry-তে সাধারণত BACKWARD, FORWARD, FULL আর NONE mode থাকে (ডিফল্ট সাধারণত BACKWARD — নিজের সংস্করণের ডকুমেন্টেশন দেখুন), আর প্রতিটির সাথে একটি ক্রম জড়িত: BACKWARD-এ নতুন schema পুরোনো ডেটা পড়তে পারে, তাই আগে সব consumer বদলান, পরে producer; FORWARD-এ পুরোনো schema নতুন ডেটা পড়তে পারে, তাই producer আগে বদলানো যায়; FULL-এ যেকোনো ক্রম। “_TRANSITIVE” রূপগুলো শুধু ঠিক আগের সংস্করণ নয়, আগের সব সংস্করণের সাথে মেলায় — log-এ মাসের পর মাস পুরোনো বার্তা জমা থাকলে (পর্ব ৩৩, log-ভিত্তিক streaming) এটিই নিরাপদ। Protobuf-এ একই কাজ হয় CI-তে: প্রতিটি pull request-এ পুরোনো আর নতুন .proto তুলনা করে বেমানান পরিবর্তন আটকানো।

API-র payload আর version. REST বা gRPC API-তেও একই নিয়ম (পর্ব ৮-এর versioning অংশ)। v1-এর ভেতরে শুধু যোগ করুন — মুছবেন না, অর্থ বদলাবেন না। Client হোক tolerant reader: অচেনা field উপেক্ষা করে, field-এর ক্রমে নির্ভর করে না। ভাঙা পরিবর্তন অনিবার্য হলে নতুন version (/v2 বা নতুন message type) পাশাপাশি চালান, আর পুরোনোটি বন্ধের সময়সূচি জানান। Mobile app-এ এটি বিশেষ জরুরি, কারণ অনেকে মাসের পর মাস app হালনাগাদ করেন না।

Database migration — expand–contract. Database-এর কলামও একটি schema, আর সেখানে ডেটা থাকে বছরের পর বছর। amount (টাকা, দশমিক) থেকে amount_paisa (পূর্ণসংখ্যা)-তে যাওয়ার নিরাপদ পথ হলো expand–contract: (১) নতুন কলাম nullable হিসেবে যোগ (expand); (২) কোড দুই কলামেই লেখে; (৩) পুরোনো সারিগুলো backfill; (৪) পড়া শুরু নতুন কলাম থেকে; (৫) পুরোনো কলামে লেখা বন্ধ; (৬) সব পুরোনো কোড বিদায় নিলে পুরোনো কলাম মুছে ফেলা — এটাই contract ধাপ। প্রতিটি ধাপ আগের ধাপের কোডের সাথে মানানসই, তাই rolling deploy-এর মাঝেও কিছু ভাঙে না। Zero-downtime migration-এর পুরো কৌশল আসবে পর্ব ৫৩-এ (deployment আর release); ORM-এর migration টুল দেখুন DBMS ও SQL-এর ORM আর migration পর্বে। Event sourcing-এ (পর্ব ৩৫) event কখনো মোছা হয় না, তাই দশ বছর আগের event-ও আজকের কোডকে পড়তে হয় — সেখানে পরীক্ষা আরও কঠিন।

৯ · AI-এর যুগে serialization আর schema

AI-কে “কোন format ভালো?” জিজ্ঞেস করলে সুন্দর তুলনা আসে, কিন্তু কিছু ভুল বারবার দেখা যায় — আর সেগুলো ধরা পড়ে সাধারণত production-এ, দেরিতে:

আরেকটি পরিচিত গোলমাল: AI প্রায়ই ACID-এর consistency (নিয়ম ও constraint রক্ষা), CAP-এর consistency (সব কপি থেকে সর্বশেষ মান) আর schema-র compatibility গুলিয়ে ফেলে — তিনটি আলাদা ধারণা (পর্ব ২৪, ৪০)।

Schema বদলের আগে — চেকলিস্ট

• প্রতিটি পরিবর্তনের backward আর forward দিক আলাদা করে যাচাই করেছি
• নতুন field optional আর default-সহ; মুছে ফেলা number আর নাম reserved
• Deploy-এর ক্রম (reader আগে না writer আগে) আর rollback-এর পথ লিখে রেখেছি; প্রতিটি সংস্করণ-জোড়ার failure-mode review করেছি
• পড়া-বদলানো-লেখার পথে অচেনা field হারায় না, পরীক্ষা করে দেখেছি
• হিসাব নিজে আবার করেছি; আকার আর গতির দাবি নিজের payload-এ ছোট load test বা simulation চালিয়ে মেপেছি
• টুলের ডিফল্ট আর সীমা অফিশিয়াল ডকুমেন্টেশনে মিলিয়েছি