دو موضع، یک پرسش
والمارت کانالی محدود برای عامل‌های خرید گشوده است، با قواعدی که تعیین می‌کند عامل چه چیزی را می‌تواند مرور کند، بخرد و نمایندگی کند. آمازون عامل‌ها را در مرز بیرونی مسدود می‌کند. هر دو موضع قابل دفاع‌اند و هیچ‌کدام نبرد بر سر استانداردها نیست. اختلاف بر سر این است که هزینهٔ تراکنش مورد مناقشه کجا فرود می‌آید.
وقتی یک خرده‌فروش عاملی را می‌پذیرد، طرفی را می‌پذیرد که انگیزه‌ها، لاگ‌ها و هویت آن را کنترل نمی‌کند. خریدی که principal بعداً آن را انکار می‌کند، سبدی که از دادهٔ محصول بدخوانده‌شده ساخته شده، کوپنی که خارج از شرایطش اعمال شده — هر یک به chargeback یا بازپرداختی تبدیل می‌شود بدون رد شواهد روشن. کانال محدود والمارت راهی است برای این که آن رد پیش از تراکنش وجود داشته باشد. مسدودسازی مرزی آمازون راهی است برای این که آن رد اصلاً پذیرفته نشود. هیچ‌کدام از این انتخاب‌ها دربارهٔ این نیست که آیا عامل‌ها از نظر فنی می‌توانند تراکنش کنند. کار زیرساختی عامل‌محور Cloudflare و یکپارچه‌سازی‌های storefront در Commerce.com نشان می‌دهند که لوله‌کشی تا حد زیادی آماده است. آنچه حل‌نشده مانده داوری است: چه کسی تصمیم می‌گیرد و بر پایهٔ کدام رکورد، وقتی خریدی با واسطهٔ عامل به خطا می‌رود.
این دو سیگنال عمومی تنها در صورتی متناقض خوانده می‌شوند که پرسش را در قالب پذیرش پروتکل بچینیم. در قالب تخصیص مسئولیت، آن‌ها همان تصمیم‌اند که در نقاط مختلف پشته گرفته شده — یک خرده‌فروش دروازهٔ انطباق می‌سازد، دیگری تا زمانی که دروازه‌ای مورد اعتمادش وجود نداشته باشد از طرف مقابل بودن سر باز می‌زند.
آنچه عامل باید حمل کند
mandate سندی است که عامل را برای خرده‌فروش خوانا می‌کند. باید امضاشده، محدود و ماشین‌بررسی‌پذیر باشد و دست‌کم چهار واقعیت را حمل کند:
- Principal. طرف حقوقی که عامل به نمایندگی او عمل می‌کند، به شکلی شناسایی‌شده که خرده‌فروش بتواند مستقل از ادعای خود عامل آن را تأیید کند.
- پوشش بودجه. یک سقف ارزش، یک ارز و یک بازهٔ اعتبار — نه موجودی جاری‌ای که عامل دربارهٔ خودش گزارش می‌دهد.
- دامنهٔ کاتالوگ. محصولات، دسته‌ها یا SKUهایی که عامل مجاز است علیه آن‌ها تراکنش کند، به صورت یک گزارهٔ ماشین‌بررسی‌پذیر و نه متن آزاد.
- انقضا. یک توقف قطعی که پس از آن mandate بی‌اثر است، تا mandate لو‌رفته یا بازپخش‌شده به درخواستی ردشده تنزل یابد.
در کنار mandate، خرده‌فروش به رسیدی نیاز دارد که بتواند بدون اعتماد به لاگ‌های فروشندهٔ عامل تأییدش کند: رکوردی امضاشده از آنچه درخواست شد، آنچه بازگشت و کدام بند mandate آن را مجاز کرد. رسید شواهد خرده‌فروش در یک مناقشه است و باید در مرز بیرونی تولید شود، نه بعداً از روایت عامل بازسازی شود.
در نهایت، مسیر مناقشه‌ای که از فروشندهٔ عامل عبور نکند. اگر تنها روایت یک خرید ناموفق، تله‌متری خود عامل باشد، از خرده‌فروش خواسته شده به طرفی اعتماد کند که رفتارش زیر سؤال است. داوری به رکوردی نیاز دارد که هر دو طرف بتوانند آن را علیه یک طرح امضای مشترک بررسی کنند.
این رمزنگاری عجیب و غریب نیست. همان شکل یک درخواست API امضاشده با توکن محدود است، به‌علاوهٔ یک مصنوع حسابرسی پایدار و مستقل قابل تأیید. بخش سخت توافق بر سر این است که مصنوع پیش از نخستین تراکنش چه باید دربرداشته باشد، نه ساختن آن.
چرا قواعد سخت طراحی مسئولیت است
یک عامل مقید به قاعده به خرده‌فروش آزمون انطباق در مرز بیرونی می‌دهد. خرده‌فروش می‌تواند درخواستی را که از دامنه، بودجه یا انقضای mandate فراتر می‌رود پیش از جابه‌جایی هر موجودی رد کند، و ردکردن ارزان است: یک بررسی واحد علیه یک سند امضاشده. این به‌طور محسوس ارزان‌تر از بازبینی تقلب پس‌ازواقع است، که مستلزم بازسازی قصد از لاگ‌های ناقص پس از جابه‌جایی پول و احتمالاً ارسال کالا است.
یک عامل بی‌حدومرز آن هزینه را به خرده‌فروش منتقل می‌کند. اگر دامنهٔ عامل مبهم باشد، خرده‌فروش نمی‌تواند انطباق را در لبه بیازماید؛ تنها می‌تواند پیامدها را مشاهده و مناقشات را پس از وقوع داوری کند. هر خرید مبهم به یک بازبینی تبدیل می‌شود و هر بازبینی حاشیهٔ سود را می‌بلعد. این موضع مسدودسازی را بهتر از هر ادعایی دربارهٔ نوآوری توضیح می‌دهد. خرده‌فروشی که نمی‌تواند مسیر مناقشه را قیمت‌گذاری کند، به‌طور عقلانی از یکپارچه‌سازی سر باز می‌زند، چون هزینهٔ مورد انتظار داوری بی‌کران است در حالی که سود مورد انتظار حدسی است.
معاملهٔ صادقانه این است که قواعد سخت حجم را سرکوب می‌کنند. mandateای که کاتالوگی محدود و بودجه‌ای سخت را نام می‌برد، برخی خریدهای مشروع را که یک خریدار انسانی انجام می‌داد رد خواهد کرد. خرده‌فروش تبدیل کمترِ عامل‌محور را در ازای هزینهٔ مناقشهٔ محدود می‌پذیرد. این یک معاملهٔ عامدانه است، نه شکست در جاه‌طلبی. خرده‌فروشی که کانال محدود می‌گشاید پیش‌بینی‌پذیری می‌خرد؛ خرده‌فروشی که مسدود می‌کند از مسئولیتی قیمت‌نخورده سر باز می‌زند. هر دو همان حساب را با فرض‌های متفاوت دربارهٔ این که داوری چند وقت یک‌بار لازم می‌شود انجام می‌دهند.
قاعدهٔ طراحی برای یکپارچه‌سازی
با mandate به‌عنوان سندی امضاشده و محدود با دامنهٔ ماشین‌بررسی‌پذیر رفتار کنید. با عامل به‌عنوان کلاینت غیرقابل‌اعتماد storefront رفتار کنید — چون همین است. storefront باید mandate را در مرز بیرونی اعتبارسنجی کند، رسید امضاشده را ثبت کند و هر چیزی خارج از دامنه را پیش از دست‌زدن به موجودی رد کند. ادعاهای خود عامل دربارهٔ آنچه انجام داده شواهد نیست؛ رکورد امضاشده شواهد است.
مسیر مناقشه را پیش از نخستین تراکنش در یکپارچه‌سازی قیمت‌گذاری کنید. این یعنی از پیش تصمیم بگیرید که یک رسید معتبر چه دربردارد، چه کسی می‌تواند آن را تأیید کند و وقتی mandate معتبر است اما خرید همچنان مورد مناقشه است چه اتفاقی می‌افتد. اگر آن مسیر طراحی نشود، در نخستین chargeback کشف خواهد شد، در نامناسب‌ترین لحظه و به هزینهٔ خرده‌فروش.
لایهٔ پروتکل در حال همگرایی است. لایهٔ مسئولیت نه، و به‌خودی‌خود همگرا نخواهد شد. رکورد mandate همان جایی است که واگرایی میان خرده‌فروش‌های پذیرا و مسدودکننده واقعاً زندگی می‌کند، و همان سطحی است که تیم یکپارچه‌سازی باید نخست طراحی کند.
نخست چه بسازیم
پیش از ارزیابی چارچوب‌های عامل یا افزونه‌های storefront، طرح‌وارهٔ mandate و طرح‌وارهٔ رسید را بنویسید. آن‌ها را علیه سه حالت شکستی که اهمیت دارند بیازمایید: خریدی خارج از دامنه، خریدی درون دامنه که principal آن را انکار می‌کند، و mandateای که پس از انقضا بازپخش شده. اگر طرح‌واره‌ها نمی‌توانند این سه را بدون توسل به لاگ‌های فروشندهٔ عامل داوری کنند، یکپارچه‌سازی آماده نیست، فارغ از این که چند پروتکل را می‌فهمد. خرده‌فروش‌هایی که حرکت کرده‌اند — در هر جهت — دربارهٔ آن داوری تصمیم گرفته‌اند. بقیه آن را به تعویق می‌اندازند.