کلیدهای تکرارناپذیری (Idempotency) و معماری جلوگیری از پرداخت‌های دوتایی در یکپارچه‌سازی سیستم‌ها

جریان‌های داده تکراری و فعال‌سازی چندباره یک تراکنش مالی واحد، از بحرانی‌ترین ریسک‌های عملیاتی در نرم‌افزارهای مالی و زیرساخت‌های تجارت الکترونیک محسوب می‌شوند. به ویژه در شرایط ضعیف شبکه یا در مواقع بروز خطای زمان‌اتمام (timeout) در سمت کلاینت، کلاینت‌ها تمایل دارند همان درخواست را مجدداً ارسال کنند. این وضعیت می‌تواند در پس‌زمینه منجر به هزینه‌های سنگین و ناسازگاری‌های داده‌ای شود. همان‌طور که ما در Cy Logic Software در فرآیندهای Sistem Entegrasyonları خود بررسی می‌کنیم، مکانیسم‌های جلوگیری از پرداخت دوتایی در چنین سناریوهایی از اهمیت حیاتی برخوردارند.

مفهوم تکرارناپذیری (Idempotency) و منطق بنیادین آن

تکرارناپذیری (Idempotency) یک اصل ریاضی و معماری است که تضمین می‌کند صرف‌نظر از اینکه یک عملیات چند بار متوالی فراخوانی شود، وضعیت نهایی سیستم پس از اولین فراخوانی دست‌نخورده باقی بماند. در بستر امنیت API و نرم‌افزارهای مالی، از این مفهوم برای جلوگیری از پردازش دوگانه یک دستور پرداخت یا درخواست انتقال در لایه شبکه استفاده می‌شود.

هنگامی که یک کلاینت درخواستی را به سرور ارسال می‌کند، یک شناسه درخواست منحصربه‌فرد (کلید تکرارناپذیری یا idempotency key) تولید می‌کند. این کلید در طول چرخه حیات درخواست حفظ شده و در لایه پایگاه داده پردازش می‌شود.

طراحی در سطح پایگاه داده: راه حل با PostgreSQL

برای راه‌اندازی یک مکانیسم تکرارناپذیری ایمن در PostgreSQL، باید محدودیت‌های منحصربه‌فردی (unique constraint) در جدول درخواست‌ها تعریف شود. مراحل پردازش به شکل زیر سازماندهی می‌شوند:

• کلاینت، کلید تکرارناپذیری را به همراه درخواست API در یک هدر سفارشی ارسال می‌کند.
• سرور تلاش می‌کند این کلید را در ستون منحصربه‌فرد جدول مربوطه در پایگاه داده رابطه‌ای ذخیره کند.
• اگر کلید از قبل ذخیره شده باشد، پایگاه داده خطای نقض انحصار (unique violation) را برمی‌گرداند و سیستم به جای راه‌اندازی یک عملیات جدید، نتیجه عملیات قبلی را بازمی‌گرداند.
• اگر عملیات هنوز کامل نشده باشد، وضعیت «در حال پردازش» برگردانده شده و از درخواست‌های همزمان (concurrent) جلوگیری می‌شود.

امنیت API و مدیریت درخواست در یکپارچه‌سازی سیستم‌ها

تاخیرهای شبکه در طول یکپارچه‌سازی سیستم‌های شخص ثالث اجتناب‌ناپذیر است. ارتباط بین سرویس‌ها در پروژه‌های یکپارچه‌سازی سیستم باید امن و قابل ردیابی باشد. استفاده از UUID در سمت کلاینت، احتمال بروز تداخل را تقریباً به صفر می‌رساند. در لایه امنیت API، مدت‌زمان اعتبار (TTL) کلیدهای ورودی باید تعیین شده و کلیدهای قدیمی به‌طور دوره‌ای پاکسازی شوند.

مدیریت خطا و کش کردن پاسخ

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

• اگر عملیات از پیش با موفقیت انجام شده باشد، پاسخ اولین درخواست را مستقیماً برمی‌گرداند.
• اگر عملیات با خطا مواجه شده باشد، همان خطا را منعکس می‌کند تا کلاینت وضعیت سازگاری را مشاهده کند.

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

سناریوی کاری فرضی: یکپارچه‌سازی درگاه پرداخت

فرض کنید یک پلتفرم تجارت الکترونیک با یک ارائه‌دهنده پرداخت شخص ثالث یکپارچه شده است. هنگامی که مشتری روی دکمه «تکمیل پرداخت» کلیک می‌کند، یک کلید تکرارناپذیری مبتنی بر UUID در سمت کلاینت تولید شده و به هدر درخواست پرداخت اضافه می‌شود. به دلیل اتصال ضعیف تلفن همراه، کلاینت پاسخ زمان‌اتمام (timeout) را از سرور پرداخت دریافت می‌کند، اما در واقع پرداخت با موفقیت در شبکه مالی پردازش شده است. کلاینت خطای شبکه را تشخیص داده و به طور خودکار همان درخواست را با همان کلید تکرارناپذیری مجدداً فعال می‌کند.

در این سناریو، درگاه API در پس‌زمینه درخواست را دریافت کرده و بررسی محدودیت منحصربه‌فرد (unique constraint) را در پایگاه داده اجرا می‌کند. سیستم تشخیص می‌دهد که کلید مربوطه همین الان پردازش شده و حتی پرداخت تکمیل شده است. به جای دریافت مجوز جدید از بانک، پاسخ اولین تراکنش موفق که در پایگاه داده کش شده است را بلافاصله به کلاینت برمی‌گرداند. بدین ترتیب از کسر مجدد مبلغ از حساب مشتری جلوگیری می‌شود. بزرگ‌ترین بده‌بستان (trade-off) در این فرآیند، افزایش جزئی هزینه نوشتن در پایگاه داده است؛ اما این هزینه در مقایسه با خسارات مالی و عملیاتی ناشی از یک پرداخت دوتایی احتمالی، در سطح قابل چشم‌پوشی قرار دارد. در درخواست‌های ناموفق نیز کد وضعیت و جزئیات خطا ذخیره شده و پیام خطای سازگاری به کلاینت منتقل می‌شود.

چک‌لیست پیاده‌سازی تکرارناپذیری و معماری پرداخت دوتایی

برای راه‌اندازی یک مکانیسم تکرارناپذیری امن در یکپارچه‌سازی سیستم‌ها و مدیریت سناریوهای خطای احتمالی، مراحل زیر باید به صورت کامل اجرا شوند:

• UUID در سمت کلاینت: اطمینان حاصل شود که برای هر تراکنش مالی جدید، یک UUID منحصربه‌فرد که احتمال تداخل را از بین می‌برد، در سمت کلاینت تولید می‌شود.
• انحصار در پایگاه داده: محدودیت 'UNIQUE' باید روی ستون کلید تکرارناپذیری در PostgreSQL یا پایگاه‌های داده رابطه‌ای مشابه تعریف شود.
• قفل همزمانی: برای جلوگیری از درخواست‌های تکراری دریافتی به صورت همزمان، قفل‌های سطری پایگاه داده (row-level locks) یا پرچم‌های وضعیت «در حال پردازش» (processing) باید به طور فعال استفاده شوند.
• کش کردن پاسخ: کد وضعیت HTTP و بدنه پاسخ مربوط به اولین درخواست باید در یک جدول امن ذخیره شود و در درخواست‌های تکراری، این پاسخ مستقیماً بازگردانده شود.
• TTL و پاکسازی: به منظور جلوگیری از تورم پایگاه داده، یک عمر مفید (TTL) برای کلیدهای تکرارناپذیری قدیمی تعیین شده و کارهای پاکسازی دوره‌ای (cron jobs) اجرا شوند.
• مدیریت زمان‌اتمام شبکه: زمان‌اتمام (timeout) بین کلاینت و سرور باید بهینه شود و سیاست‌های تلاش مجدد (retry) در صورت بروز خطا باید مطابق با قوانین تکرارناپذیری پیکربندی شوند.

این ساختار ضمن به حداکثر رساندن یکپارچگی داده‌ها در فرآیندهای یکپارچه‌سازی سیستم، جریان مالی پیوسته‌ای را مطابق با استانداردهای Sistem Entegrasyonları ارائه شده توسط Cy Logic Software فراهم می‌کند.

منابع

• Sistem Entegrasyonları — Cy Logic Software