2 پست با برچسب "سامانه‌های داده‌محور"

اولش همه‌چیز ساده بود. یک سرویس رویدادی منتشر می‌کرد و یک مصرف‌کننده هم آن را می‌خواند. تولیدکننده لازم نبود مصرف‌کننده را بشناسد، اگر مصرف‌کننده برای مدتی از دسترس خارج می‌شد پیام از بین نمی‌رفت و هر دو طرف می‌توانستند با سرعت خودشان جلو بروند.

همان چیزی بود که از معماری رویدادمحور می‌خواستیم: وابستگی کمتر و استقلال بیشتر.

بعد مصرف‌کننده‌ی دوم اضافه شد. بعدی برای گزارش، یکی برای اعلان، یکی برای ضدتقلب و یکی هم برای ساختن داده‌های تحلیلی. چند نسخه از رویداد شکل گرفت، بعضی مصرف‌کننده‌ها عقب ماندند و یک تغییر کوچک در قرارداد، جایی دورتر از تولیدکننده را شکست.

قرار بود سرویس‌ها مستقل شوند؛ اما حالا وابستگی‌ها فقط از جلوی چشممان ناپدید شده بودند.

فرض کن نسخه‌ی تازه‌ی سرویس سفارش را مستقر کرده‌ایم. چند دقیقه‌ی اول، همه‌چیز عادی به نظر می‌رسد: نمودارها وضعیت بدی نشان نمی‌دهند، نرخ خطا بالا نرفته، و از بیرون انگار سامانه دارد کار می‌کند. کمی بعد، پشتیبانی خبر می‌دهد که چند پرداخت موفق بوده، اما سفارش در پنل کاربر دیده نمی‌شود. لاگ‌ها را باز می‌کنیم، متریک‌ها را می‌بینیم، تریس‌ها را دنبال می‌کنیم؛ داده کم نیست، اما جواب روشن پیدا نمی‌شود. معلوم نیست مشکل از پرداخت است، صف پیام، موجودی، نسخه‌ی تازه، یا داده‌ای که در میانه‌ی مسیر نیمه‌کاره مانده است.

من معمولاً همین‌جا تفاوت میان «کار کردن» و «قابل اداره بودن» را می‌بینم. سامانه ممکن است تا حدی زنده باشد، درخواست بگیرد و حتی بیشتر مسیرها را درست پاسخ بدهد، اما در لحظه‌ی تغییر یا اختلال، برای تیم قابل فهم نباشد. قابلیت اداره‌پذیری، یا operability، درباره‌ی همین لحظه‌هاست: لحظه‌هایی که باید بفهمیم چه رخ داده، آسیب را محدود کنیم، تصمیمی امن بگیریم، و اگر لازم شد از مسیر اشتباه برگردیم.