API کے ساتھ کام کرتے وقت آرڈرز کی نقل: وجوہات اور تحفظ

ایک عمل کے بعد نقل کیوں پیدا ہوتی ہے

پینل کا مالک ایک بار بٹن دبا سکتا ہے اور کئی ایک جیسے آرڈرز دیکھ سکتا ہے: سبسکرائبرز، ویوز، ری ایکشنز یا کوئی اور سروس۔ عام طور پر مسئلہ خود کلک میں نہیں، بلکہ کلائنٹ، API، ڈیٹا بیس اور سپلائر کے درمیان زنجیر میں ہوتا ہے۔

سرور کے نقطہ نظر سے ”ایک درخواست“ ہمیشہ ایک نہیں ہوتی۔ کلائنٹ کو جواب نہ مل سکے، وہ دوبارہ بھیج دے، اور پہلا عمل پہلے ہی محفوظ ہو چکا ہو۔ کبھی آرڈر پینل کے ڈیٹا بیس میں ایک بار بنتا ہے، لیکن سپلائر کو دو بار جاتا ہے۔ یہ مختلف صورتحال ہیں، اور انہیں مختلف طریقوں سے ٹھیک کیا جاتا ہے۔

ٹائم آؤٹ کا مطلب یہ نہیں کہ آرڈر نہیں بنا

سب سے عام وجہ یہ ہے کہ کلائنٹ محدود وقت تک جواب کا انتظار کرتا ہے۔ سرور درخواست وصول کرتا ہے، آرڈر بناتا ہے، لیکن مقررہ ٹائم آؤٹ کے بعد جواب دیتا ہے۔ کلائنٹ عمل کو ناکام سمجھتا ہے اور اسے دوبارہ بھیجتا ہے۔

نتیجے میں پہلا آرڈر پہلے ہی ڈیٹا بیس میں موجود ہوتا ہے، اور دوسری درخواست ایک اور بنا دیتی ہے۔ یہ خاص طور پر بیرونی API کے سست جواب، بوجھل قطار یا سروسز کے درمیان غیر مستحکم کنکشن کی صورت میں کثرت سے ہوتا ہے۔

ٹائم آؤٹ صرف جواب نہ ملنے کی بات کرتا ہے، درخواست پر کارروائی نہ ہونے کی نہیں۔

کلائنٹ کی طرف خودکار دوبارہ کوششیں

HTTP درخواستوں کے لیے لائبریریاں، پس منظر کے کام اور انٹیگریشن سروسز اکثر درخواست خودکار طور پر دوبارہ بھیج دیتی ہیں۔ اس کی وجہ کنکشن کی خرابی، سرور کے جواب کا کوڈ، نیٹ ورک کا ٹوٹنا یا بہت طویل جواب ہو سکتا ہے۔

دوبارہ کوشش بذات خود مفید ہے: یہ عارضی خرابیوں کے دوران ضائع ہونے والے آرڈرز کی تعداد کم کرتی ہے۔ اس طریقے کی کمی یہ ہے کہ دوبارہ کارروائی سے تحفظ کے بغیر یہ نیٹ ورک کی ہر عدم استحکام کو نقل میں بدل دیتا ہے۔

• دوبارہ کوشش سائٹ یا بوٹ کے کوڈ میں شروع ہو سکتی ہے؛
• کام کو قطار دوبارہ شروع کر سکتی ہے؛
• درخواست کو پروکسی یا انٹیگریشن ماڈیول دوبارہ بھیج سکتا ہے؛
• آپریٹر خرابی کے بعد آرڈر دستی طور پر دوبارہ بھیج سکتا ہے۔

دوبارہ درخواست پہلے جواب سے پہلے آ جاتی ہے

کبھی دو ایک جیسی درخواستیں واقعی تقریباً ایک ہی وقت میں API تک پہنچ جاتی ہیں۔ مثلاً صارف نے فارم دو بار بھیج دیا، فرنٹ اینڈ نے بٹن بلاک نہیں کیا یا پس منظر کا کام پہلے کے مکمل ہونے سے پہلے دوبارہ شروع ہو گیا۔

اگر ہینڈلر پہلے آرڈر کی موجودگی چیک کرتا ہے اور پھر اسے بناتا ہے، تو دو متوازی عمل ایک ہی وقت میں چیک پاس کر سکتے ہیں۔ ہر ایک دیکھے گا کہ آرڈر ابھی نہیں ہے، اور ہر ایک نئی اندراج شامل کرے گا۔

ایسی صورتحال کو ریس کنڈیشن کہا جاتا ہے۔ کوڈ میں سادہ پیشگی جانچ اس سے مکمل تحفظ نہیں دیتی۔ ڈیٹا بیس کی سطح پر پابندی کے بغیر جانچ کی کمی یہ ہے کہ متوازی بوجھ میں یہ ناکام ہو جاتی ہے۔

آرڈر محفوظ ہو گیا، لیکن API کا جواب گم ہو گیا

درخواست کئی مراحل سے گزرتی ہے: سرور ڈیٹا وصول کرتا ہے، اندراج بناتا ہے، کام کو قطار میں ڈالتا ہے، جواب بھیجتا ہے۔ ان میں سے کسی بھی مرحلے کے دوران خرابی ممکن ہے۔ مثلاً ڈیٹا بیس نے آرڈر بننے کی تصدیق کر دی، لیکن کلائنٹ کو جواب منتقل ہونے سے پہلے کنکشن ٹوٹ گیا۔

کلائنٹ کو معلوم نہیں کہ آرڈر قبول ہوا یا نہیں، اور وہ عمل دہراتا ہے۔ الگ جانچ کے طریقے کے بغیر API درخواست کو نیا سمجھتی ہے۔ لاگ میں یہ اکثر ایسا دکھتا ہے جیسے سروس نے دو آرڈر ”خود“ بنائے ہوں، حالانکہ اس کے پاس دو آنے والی کالیں تھیں۔

آرڈر بنانے کے لیے idempotent کلید

بنانے کے عمل کے لیے منفرد idempotency کلید درکار ہے۔ کلائنٹ اسے پہلی بار بھیجنے سے پہلے بناتا ہے اور آرڈر کے پیرامیٹرز کے ساتھ بھیجتا ہے۔ ٹائم آؤٹ یا خرابی کی وجہ سے دوبارہ بھیجنے پر وہی کلید استعمال ہوتی ہے۔

API کلید کو کارروائی کے نتیجے کے ساتھ محفوظ کرتی ہے۔ اگر پہلے سے معلوم کلید کے ساتھ درخواست آئے، تو سرور نیا آرڈر نہیں بناتا، بلکہ پہلی کال کا نتیجہ واپس کرتا ہے: آرڈر کی شناخت، اس کی حیثیت یا پہلے بنائی گئی خرابی۔

ایک کلید کو ایک کاروباری عمل کے مطابق ہونا چاہیے، نہ کہ ایک HTTP کنکشن کے۔

اس طریقے کی کمی یہ ہے کہ کلیدوں کو محفوظ رکھنا، قواعد کے مطابق صاف کرنا اور API کی طرف جانچنا ضروری ہے۔ اگر ہر دوبارہ کوشش پر نئی کلید بنائی جائے، تو تحفظ کام نہیں کرے گا۔ اگر مختلف آرڈرز کے لیے ایک ہی کلید استعمال ہو، تو کچھ نئے عمل غلط طور پر مسترد ہو جائیں گے۔

منفرد ہونے کا کنٹرول ڈیٹا بیس میں ہونا چاہیے

Idempotency کو ڈیٹا بیس میں منفرد پابندی کے ساتھ بہتر بنانا چاہیے۔ اس کے لیے ایسا امتزاج منتخب کیا جاتا ہے جو آرڈر کو واضح طور پر بیان کرے: کلائنٹ کی اندرونی شناخت، idempotency کلید، سروس کی قسم اور دیگر مطلوبہ فیلڈز۔

ڈیٹا بیس کو دوسرا اندراج مسترد کرنا چاہیے، چاہے دو ہینڈلرز بیک وقت بنانے تک پہنچ جائیں۔ تصادم کے بعد API موجودہ آرڈر واپس کرتی ہے، نہ کہ بغیر وضاحت کے خرابی۔

سخت منفرد پابندی کی کمی یہ ہے کہ اسے صرف لنک یا username پر نہیں بنایا جا سکتا۔ کلائنٹ جان بوجھ کر ایک ہی چینل پر ایک ہی سروس کئی بار منگوا سکتا ہے۔ بہت وسیع پابندی معمول کی دوبارہ خریداریوں کو بلاک کر دے گی۔

قطار کام کو ایک سے زیادہ بار پہنچا سکتی ہے

کام کی قطاریں اکثر ”کم از کم ایک بار ترسیل“ کے اصول پر کام کرتی ہیں۔ اگر ورکر نے کام پر کارروائی کی لیکن اسے مکمل ہونے کی تصدیق نہ کر سکا، تو قطار وہی کام دوبارہ کسی دوسرے ورکر کو دے سکتی ہے۔

قطار کے لیے یہ کام نہ کھونے کا معمول کا طریقہ ہے۔ idempotency کے بغیر آرڈر بنانے کے لیے یہ نقل کا ذریعہ ہے۔ کام کی شناخت یا عمل کی الگ کلید آخری ہینڈلر تک منتقل کرنی چاہیے، بشمول سپلائر کو آرڈر بھیجنے والے ماڈیول تک۔

دوبارہ ترسیل بند کرنے کی کمی یہ ہے کہ ورکر کے گرنے پر کچھ آرڈر غائب ہو سکتے ہیں۔ ممکنہ دہرائی کو قبول کرنا اور ہینڈلر کو ان کے لیے مزاحم بنانا زیادہ محفوظ ہے۔

نقل پینل اور سپلائر کے درمیان پیدا ہوتی ہے

اندرونی آرڈر ایک بار بن سکتا ہے، لیکن بیرونی API کو درخواست دو بار بھیجی جا سکتی ہے۔ وجہ وہی ہے: پینل کو سپلائر سے جواب نہیں ملا اور اس نے دوبارہ بھیجنے کا فیصلہ کیا۔ اگر سپلائر نے پہلی درخواست قبول کر لی تھی، تو اس کی طرف دو ایک جیسی درخواستیں ظاہر ہوں گی۔

اندرونی آرڈر کو بیرونی سے الگ جوڑنے کی ضرورت ہے: بھیجنے کی شناخت، idempotency کلید یا سپلائر کا محفوظ جواب۔ یہ نہیں سمجھا جا سکتا کہ اپنے پینل کے اندراج پر تحفظ خود بخود باہر جانے والی کالوں کی حفاظت کرے گا۔

کسی فریق ثالث API کے ساتھ موازنے کی کمی یہ ہے کہ ہر سپلائر بیرونی کلید کے ذریعے تلاش کی سہولت نہیں دیتا۔ پھر بھیجنے کی کوششیں ریکارڈ کرنی پڑتی ہیں اور غیر واضح حیثیتیں الگ سے جانچنی پڑتی ہیں۔

ویب ہک کو نیا آرڈر نہیں بنانا چاہیے

ویب ہک تبدیلیوں کی اطلاع دیتے ہیں: آرڈر قبول ہوا، شروع ہوا، مکمل ہوا، منسوخ ہوا یا جانچ کا متقاضی ہے۔ خرابی اس وقت پیدا ہوتی ہے جب ویب ہک ہینڈلر اطلاع کو آرڈر دوبارہ بنانے کا حکم سمجھ لیتا ہے۔

ایک ہی ویب ہک دوبارہ آ سکتا ہے۔ بھیجنے والا ترسیل دہراتا ہے اگر اسے تصدیق نہ ملے، اور اطلاعات کبھی ترتیب سے باہر بھی آتی ہیں۔ ہینڈلر کو بیرونی شناخت کے ذریعے موجودہ آرڈر تلاش کرنا اور حیثیت اپ ڈیٹ کرنی چاہیے۔

ویب ہک کو صرف وصولی کے وقت کی بنیاد پر پروسیس کرنے کی کمی یہ ہے کہ دیر سے آنے والی اطلاع موجودہ حیثیت کو پرانی سے اوور رائٹ کر سکتی ہے۔ ایونٹ کی شناخت، حیثیت کا ورژن یا واضح منتقلی کے قواعد درکار ہیں۔

کون سے ریکارڈ نقل کا ذریعہ تلاش کرنے میں مدد دیں گے

تحقیق کے لیے صرف دو آرڈر نمبر دیکھنا کافی نہیں۔ کارروائی کے ہر مرحلے کا ڈیٹا درکار ہے: درخواست کا وقت، idempotency کلید، کلائنٹ کی شناخت، آرڈر کے پیرامیٹرز، پس منظر کے کام کا نمبر، بیرونی API کا جواب اور دوبارہ بھیجنے کی کوششیں۔

• نقل کو صرف لنک سے نہیں، عمل کی کلید سے ملائیں؛
• جانچیں کہ آنے والی API کے لاگ میں ایک جیسی درخواستیں تھیں یا نہیں؛
• دیکھیں کہ قطار میں کام دہرایا گیا یا نہیں؛
• اندرونی آرڈر بنانے کو سپلائر کو بھیجنے سے الگ رکھیں؛
• جواب ملنے کے فوراً بعد درخواست کی بیرونی شناخت محفوظ کریں۔

بہت مختصر لاگز کی کمی یہ ہے کہ مسئلے کا ذریعہ جانچے جانے سے پہلے غائب ہو جاتا ہے۔ ضرورت سے زیادہ لاگنگ کی کمی یہ ہے کہ اندراج میں ٹوکنز، ذاتی ڈیٹا اور دیگر حساس فیلڈز آ سکتے ہیں، اس لیے انہیں ماسک کرنا ضروری ہے۔

درخواست کے غیر واضح نتیجے کو کیسے سنبھالیں

ٹائم آؤٹ کے بعد نئے ڈیٹا کے ساتھ فوراً آرڈر دوبارہ نہیں بنایا جا سکتا۔ پہلے API کو idempotency کلید یا کلائنٹ شناخت کے ذریعے عمل کی جانچ کرنی چاہیے۔ اگر آرڈر مل جائے، تو اس کی موجودہ حالت واپس کی جاتی ہے۔ اگر کارروائی ابھی جاری ہے، تو کلائنٹ کو انتظار کی حیثیت ملتی ہے۔

1. پہلی درخواست سے پہلے عمل کی کلید بنائیں۔
2. ہر دوبارہ کوشش پر وہی کلید بھیجیں۔
3. کلید اور آرڈر کو ڈیٹا بیس کے ایک محفوظ عمل میں محفوظ کریں۔
4. عمل کی شناخت قطار اور بیرونی API کو منتقل کریں۔
5. دوبارہ درخواست پر پہلے بنایا گیا آرڈر واپس کریں۔

ایسی صورتحال کے لیے API اور کلائنٹ انٹیگریشن میں تبدیلی درکار ہے۔ اس کی کمی یہ ہے کہ ڈی بگنگ مشکل اور آرڈر کی حالتیں زیادہ ہیں، لیکن درخواست کی دوبارہ ترسیل خود بخود دوبارہ خریداری کے معنی دینا بند کر دیتی ہے۔