سازمانهایی که دهها سامانه دارند، معمولاً با یک شبکهٔ درهمتنیده از اتصالات نقطهبهنقطه روبهرو هستند: هر سامانه با چند سامانهٔ دیگر مستقیماً حرف میزند، هر کدام با پروتکل و قرارداد متفاوت. نتیجه این است که تغییر یک سامانه، چند سامانهٔ دیگر را میشکند و افزودن یک کانال جدید، مثل یک اپلیکیشن موبایل، به ماهها کار یکپارچهسازی نیاز دارد. زمانی که یک تیم میخواهد بداند «آخرین تراکنش این مشتری چه بود»، باید از سه سامانه بپرسد و پاسخها را دستی ترکیب کند.
این موضوع اهمیت دارد، زیرا سرعت تحول دیجیتال یک سازمان مستقیماً به سرعت یکپارچهسازی آن وابسته است. اگر هر محصول جدید نیازمند اتصال مجدد به سامانههای مرکزی باشد، هزینهٔ آزمایش ایدههای جدید بسیار بالا میرود. علاوه بر این، هر اتصال مستقیم یک نقطهٔ امنیتی نظارتنشده است: چه کسی فراخوانی میکند، با چه مجوزی، با چه نرخی؟ بدون یک لایهٔ مشترک، پاسخ به این پرسشها برای هر اتصال جداگانه است و در عمل، هیچکس پاسخ کاملی ندارد.
معماری مطلوب، دو الگوی مکمل را کنار هم میگذارد. درگاه API نقطهٔ ورود واحد برای تعاملات همزمان است: مصرفکننده درخواست میدهد و در همان لحظه پاسخ میگیرد. درگاه، احراز هویت، مجوز، محدودیت نرخ، نسخهبندی و مشاهدهپذیری را بهشکل یکنواخت اعمال میکند. معماری رویدادمحور برای تعاملات ناهمزمان است: وقتی چیزی رخ میدهد، مثل افتتاح حساب یا تغییر نشانی، سامانهٔ منبع یک رویداد منتشر میکند و هر سامانهای که علاقهمند است، آن را مصرف میکند؛ بدون آنکه منبع بداند مصرفکنندگان چه کسانی هستند. یک صف پیام پایدار در میان این دو، تضمین میکند که هیچ رویدادی گم نشود.
نخستین ملاحظهٔ عملی، طراحی قرارداد است. API و رویداد هر دو قرارداد هستند و باید مثل قرارداد با آنها رفتار شود: با طرحوارهٔ مشخص، نسخهبندی صریح و قاعدهٔ روشن برای تغییرات سازگار و ناسازگار. برای مثال، افزودن یک فیلد اختیاری به رویداد «مشتری بهروزرسانی شد» تغییری سازگار است، اما تغییر نوع یک فیلد موجود، نسخهٔ جدیدی میطلبد که برای مدتی در کنار نسخهٔ قدیمی منتشر شود. یک مخزن مرکزی برای طرحوارهها، به تیمها اجازه میدهد پیش از استقرار، سازگاری را بهصورت خودکار بررسی کنند.
دومین ملاحظه، انتخاب درست میان همزمان و ناهمزمان است. قاعدهٔ سرانگشتی این است: اگر مصرفکننده برای ادامهٔ کار خود به پاسخ نیاز فوری دارد، از API استفاده کنید؛ اگر صرفاً باید از وقوع چیزی مطلع شود، از رویداد. استعلام موجودی، همزمان است. اطلاعرسانی به سامانهٔ ضدپولشویی دربارهٔ یک تراکنش، ناهمزمان است. بسیاری از مشکلات کارایی و وابستگی در سازمانها از آنجا ناشی میشود که تعاملات ناهمزمان با فراخوانی همزمان پیاده شدهاند و یک سامانهٔ کند، کل زنجیره را کند میکند.
سومین ملاحظه، مشاهدهپذیری سرتاسری است. وقتی یک درخواست از درگاه وارد میشود، چند سرویس را طی میکند و چند رویداد تولید میکند، تیم باید بتواند کل مسیر را با یک شناسهٔ همبستگی دنبال کند. این شناسه باید در سرآیند API و در فرادادههای رویداد منتقل شود. بدون آن، اشکالزدایی یک مشکل به همبستگی دستی زمانها در لاگهای چند سامانه تبدیل میشود که در ساعت اوج، عملاً غیرممکن است.
دامهای رایج در این حوزه چند دستهاند. اول، تبدیل درگاه API به محل منطق کسبوکار؛ درگاه باید سیاست اعمال کند، نه تصمیم کسبوکاری بگیرد. دوم، رویدادهای «چاق» که کل رکورد را حمل میکنند و مصرفکنندگان را به ساختار داخلی منبع وابسته میکنند، یا رویدادهای «لاغر» که فقط یک شناسه دارند و همه را مجبور به فراخوانی مجدد میکنند. سوم، بیتوجهی به ترتیب و تکرار؛ مصرفکننده باید بتواند رویداد تکراری را تشخیص دهد و رویداد خارج از ترتیب را مدیریت کند. و چهارم، نبود مالک برای لایهٔ یکپارچهسازی، که آن را به همان وضعیت پیشین بازمیگرداند.
در نیاداد، این سهگانه بهصورت سه پلتفرم مکمل پیاده شده است. «سپهر» درگاه API سازمانی است: احراز هویت، مجوز، محدودیت نرخ، نسخهبندی و مشاهدهپذیری برای همهٔ تعاملات همزمان. «جریان» پلتفرم رویداد است: انتشار، اشتراک و طرحوارهٔ رویدادها با ثبت تاریخچه. و «پیام» صف پیام پایدار است که تحویل تضمینشده و مدیریت خطا را برای تعاملات ناهمزمان فراهم میکند. این سه در پروژهٔ بانکی نیاداد ستون فقرات یکپارچهسازی را ساختهاند و به لایههای هویت، اشخاص و داده متصلاند.
درگاه API و معماری رویدادمحور دو پاسخ به دو پرسش متفاوتاند و سازمان بالغ هر دو را دارد. آنچه آنها را به یک زیرساخت واحد تبدیل میکند، قراردادهای صریح، هویت مشترک و مشاهدهپذیری سرتاسری است. با این سه، افزودن یک کانال یا سامانهٔ جدید از یک پروژهٔ چندماهه به کاری چندروزه تبدیل میشود. معیار واقعی یک لایهٔ یکپارچهسازی همین است: نه زیبایی نمودارش، بلکه اینکه چقدر کم سد راه تغییر بعدی میشود.