سریالایزیشن و قرارداد داده: JSON تا Schema Registry

هر پیامی که بین دو سرویس رد می‌شود — روی HTTP یا Kafka — باید به بایت تبدیل و برگردد. انتخاب فرمت و مدیریت تکامل آن، تفاوت سیستمی است که نسخه جدیدش بدون ترس دیپلوی می‌شود با سیستمی که هر تغییر کوچک، consumer هایش را می‌شکند.

سازگاری: قانون مهم‌تر از فرمت

• قواعد امن: فقط فیلد اختیاری با default اضافه کن؛ هرگز فیلد را حذف یا rename نکن؛ نوع فیلد را عوض نکن؛ در Protobuf شماره فیلد را بازیافت نکن.
• Schema Registry (مثل Confluent) کنار Kafka می‌ایستد: producer schema را ثبت می‌کند، registry سازگاری را enforce می‌کند، consumer با ID نسخه درست می‌خواند — بدون registry، topic ها به معدل‌فیل قراضه تبدیل می‌شوند.
• تغییر ناسازگار = topic جدید (مثل API v2) + مهاجرت تدریجی مصرف‌کننده‌ها.

gRPC و بقیه

• gRPC = Protobuf + HTTP/2: چهار مدل (unary ،server-streaming ،client-streaming ،bi-directional)؛ برای سرویس‌های داخلی سریع و با قرارداد سفت، ولی بدون پروکسی مرورگر مستقیم کار نمی‌کند (gRPC-Web).
• GraphQL مسئله دیگری را حل می‌کند: انعطاف کلاینت روی داده — به قیمت کش پیچیده، خطر N+1 (DataLoader درس ۳۶ را ببین) و نیاز به محدودکردن عمق کوئری.
• قرارداد هرچه باشد، در CI تست سازگاری (contract test) بگذار تا شکستن قبل از دیپلوی گرفته شود (درس ۴۷).

به زبان ساده

قرارداد داده باید مثل قرارداد رسمی نسخه داشته باشد: JSON خوانا ولی سست است، Protobuf/Avro فشرده و قانون‌مند، و Schema Registry نگهبان سازگاری نسخه‌هاست.

مثال واقعی

وقتی تولیدکننده پیام، فیلد price را به تومان تغییر می‌دهد، Schema Registry قبل از انتشار جلویش را می‌گیرد که مصرف‌کننده‌های قدیمی نشکنند — مثل کنترل نسخه قرارداد بین دو شرکت.