Idempotency چیست؟ جلوگیری از سفارش و پرداخت تکراری

سرور سفارش را ثبت می‌کند اما پاسخ در راه قطع می‌شود. کاربر دوباره تلاش می‌کند. سرور باید بفهمد با عملیات تازه روبه‌روست یا تکرار درخواست قبلی. retry بخشی از کار با شبکه است و باید در طراحی دیده شود.

قفل کردن دکمه تجربهٔ کاربری را بهتر می‌کند، اما درخواست از چند تب یا سیستم صف هم می‌رسد. کنترل پایدار باید در سرور و ذخیره‌سازی وجود داشته باشد.

POST /orders
Idempotency-Key: random-operation-key

{ "courseId": 14 }

// کلید + کاربر + نوع عملیات -> نتیجهٔ ثبت‌شده

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

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

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

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

• همان کلید و ورودی دوبار ارسال شود.
• دو درخواست همزمان برسند.
• پاسخ بعد از ثبت سفارش قطع شود.
• وبهوک تکراری یا خارج از ترتیب برسد.
• صدور دسترسی پس از پرداخت شکست بخورد.

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

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