ایک نیا Laravel-centric گائیڈ ڈویلپرز کو یہ دکھاتا ہے کہ ویب ہک (webhook) کو محفوظ بنا کر، idempotency کے لیے Redis کا استعمال کر کے اور بھاری کاموں کو کیوز (queues) پر منتقل کر کے، Telegram bots کو ٹائم آؤٹ ہونے، ایک ہی عمل کو بار بار دہرانے، یا لوڈ کے تحت کریش ہونے سے کیسے بچایا جائے۔

Telegram webhooks کو ایک سادہ روٹ سے زیادہ کی ضرورت کیوں ہے

Telegram صارف کے ہر تعامل (interaction) کو ڈویلپر کے بتائے گئے URL پر HTTP POST کے ذریعے بوٹ کو بھیجتا ہے۔ پلیٹ فارم چند سیکنڈ کے اندر 200 OK کی توقع رکھتا ہے؛ اگر اس سے زیادہ وقت لگے تو یہ درخواست کو دوبارہ بھیجتا (retry) ہے۔ ری ٹرائی کا مطلب ہے کہ ایک ہی update_id کئی بار آ سکتا ہے، اور اگر بوٹ درخواست کے دوران ڈیٹا بیس میں کچھ لکھتا ہے یا بیرونی APIs کو کال کرتا ہے، تو یہ ڈپلیکیٹ روز (rows)، دوہرے پیغامات، یا race conditions پیدا کر سکتا ہے۔ ان بوٹس کے لیے جو فی سیکنڈ درجنوں یا سینکڑوں پیغامات سنبھالتے ہیں، یہ تاخیر (latency) تیزی سے ایک رکاوٹ بن جاتی ہے۔

1. ایک خفیہ ہیڈر (secret header) کے ذریعے اینڈ پوائنٹ کو محفوظ بنائیں

Telegram ہر webhook کال میں X-Telegram-Bot-Api-Secret-Token ہیڈر شامل کرتا ہے۔ اس ہیڈر کا موازنہ سرور پر محفوظ شدہ ایک خفیہ ٹوکن سے کریں—تاکہ timing attacks سے بچا جا سکے اس کے لیے PHP کے hash_equals فنکشن کا استعمال کریں—اور کسی بھی ایسی درخواست کو مسترد کر دیں جو Telegram سے نہ آئی ہو۔ Laravel میں، اس چیک کو middleware میں رکھیں تاکہ کنٹرولر کے payload کو چھونے سے پہلے تصدیق مکمل ہو جائے۔

2. Redis کے ذریعے ہر اپ ڈیٹ کو idempotent بنائیں

ہر آنے والے payload کے ساتھ ایک منفرد update_id ہوتا ہے۔ یہ گائیڈ اس ID کو NX (set-if-not-exists) فلیگ کے ساتھ Redis میں لکھنے کا مشورہ دیتی ہے۔ یہ آپریشن صرف پہلی بار کامیاب ہوتا ہے؛ ری ٹرائی کی صورت میں کی (key) پہلے سے موجود ملتی ہے اور webhook فوری طور پر 200 OK واپس کر سکتا ہے، جس سے Telegram کو اشارہ مل جاتا ہے کہ اپ ڈیٹ کو ہینڈل کر لیا گیا ہے۔ چونکہ Redis میموری میں ہوتا ہے، اس لیے یہ چیک تقریباً کوئی تاخیر (latency) پیدا نہیں کرتا، اور ڈپلیکیٹس کا پتہ لگانے کے لیے کی (key) موجود رہتی ہے۔

3. بھاری کاموں کو بیک گراؤنڈ جابز (background jobs) کے سپرد کریں

تیز رفتار Redis چیک کے باوجود، بوٹ کی بزنس لاجک—جیسے ڈیٹا بیس رائٹس، تھرڈ پارٹی API کالز، اور میسج کمپوزیشن—کو کبھی بھی webhook درخواست کے اندر نہیں چلنا چاہیے۔ جیسے ہی webhook کی تصدیق ہو جائے اور update_id محفوظ ہو جائے، فوراً ایک Laravel queued job ڈسپچ کریں۔ HTTP رسپانس فوری طور پر بھیج دیں، تاکہ ورکر اپنی رفتار سے جاب کو پروسیس کر سکے۔ اس سے بوٹ Telegram کی رسپانس ڈیڈ لائن کے اندر رہتا ہے اور پلیٹ فارم کو دوبارہ کوشش (retry) کرنے سے روکتا ہے۔

پروڈکشن گریڈ (Production-grade) بہتری کے طریقے

  • ریٹ لمٹس (rate limits) کا احترام کریں۔ جب کوئی بوٹ اپنی فی سیکنڈ کی حد سے تجاوز کرتا ہے تو Telegram Retry-After ہیڈر کے ساتھ 429 Too Many Requests واپس کرتا ہے۔ Queue workers کو چاہیے کہ وہ اس ہیڈر کو پڑھیں اور ناکام شدہ جاب کو دوبارہ کرنے سے پہلے وقفہ لیں۔
  • جواب دینے سے پہلے ڈیٹا محفوظ کریں۔ کسی بھی صارف کے ڈیٹا کو پہلے ڈیٹا بیس میں لکھیں؛ بوٹ کو تصدیقی پیغام صرف کامیاب کمٹ (commit) کے بعد ہی بھیجنا چاہیے۔ یہ ترتیب ان حالات سے بچاتی ہے جہاں پیغام صارف تک پہنچ جاتا ہے لیکن متعلقہ ریکارڈ کبھی بن ہی نہیں پاتا۔
  • callback payloads کو محدود رکھیں۔ Telegram callback_data کو 64 bytes تک محدود رکھتا ہے۔ حد کے اندر رہنے کے لیے بڑے ڈیٹا (blobs) کو ڈیٹا بیس میں محفوظ کریں اور بٹن پے لوڈ میں صرف ایک ریفرنس آئی ڈی (reference ID) پاس کریں۔

خلاصہ: درخواست کی تصدیق کرنا، Redis کے ذریعے ڈپلیکیٹس کو ختم کرنا اور کاموں کو کیوز (queues) پر منتقل کرنا Laravel ڈویلپرز کو ایسے Telegram bots بنانے کی اجازت دیتا ہے جو فوری جواب دیتے ہیں، ریٹ لمٹس کے اندر رہتے ہیں اور صارفین کی طلب بڑھنے کے ساتھ آسانی سے اسکیل (scale) ہو سکتے ہیں۔