پلتفرم رزرو هوشمند

مسئله تجاری

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

آنچه تحویل دادم

• پایه‌ی بیعانه و رزرو، طوری که رزرو فقط پس از پرداخت تأییدشده ساخته شود، نه به امید آن.
• idempotency روی کال‌بک پرداخت ووکامرس: اعلان تکراری برای یک پرداخت، همان یک رزرو را می‌دهد نه یکی بیشتر.
• ظرفیت و قواعد زمانی که ادمین تعریف می‌کند، تا محدودیت‌ها پیکربندی باشند نه کد سفت.
• تاریخچه و خط زمانی وضعیت روی رکورد، تا بعداً بشود دید یک رزرو از چه حالت‌هایی گذشته است.
• لایه‌ی رویداد و ممیزی زیر آن، تا تغییر وضعیت همان لحظه ثبت شود، نه اینکه بعداً از ردیف فعلی حدس زده شود.
• فلگ و مدیریت اسکیمای مستقل، تا این بخش جدا از بقیه‌ی پلتفرم توسعه و فعال شود.

رویکرد فنی

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

نتیجه و شواهد

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

اهمیت برای کارفرما

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