مغازهداری که منتظر محمولهای است دو راه پیش رو دارد: هر ربع ساعت زنگ بزند و بپرسد «رسیده؟»، یا شمارهاش را بدهد و بنشیند تا انبار، خودش خبرش کند. نرمافزارها دقیقاً همین دو راه را دارند؛ به یکی Polling یا پرسوجوی دورهای و به دیگری Webhook یا قلاب وب میگویند. انتخاب میان این دو، شکل معماری، حجم ترافیک و حتی تأخیر خبررسانی به کاربر را تعیین میکند.
مسئله از جایی شروع میشود که دو سامانه حافظه مشترکی ندارند: سامانه پرداخت نمیداند فروشگاه چه زمانی منتظر خبر است و فروشگاه هم نمیداند پرداخت کی انجام میشود. در این مقاله این مسئله را باز میکنیم، پیامد انتخاب غلط را میبینیم و با راهکار رویدادمحور و جدول مقایسه، تصمیمگیری را ساده میکنیم.
مسئله: خبر از کدام مسیر بیاید؟
تقریباً هر یکپارچهسازی (Integration) میان دو سامانه، در نهایت به یک پرسش میرسد: بعد از رخداد، چه کسی به کی خبر میدهد؟ پرداخت موفق شد، سفارش آماده شد، فایل پردازش تمام شد؛ اطلاعات تازه در سمت فرستنده است و گیرنده باید راهی برای فهمیدن آن داشته باشد. دو الگوی اصلی برای همین پرسش وجود دارد و هر کدام معنای متفاوتی از «بهموقع بودن» میسازد.
Polling: پرسوجوی دورهای
در Polling، گیرنده در بازههای زمانی مشخص به فرستنده سر میزند و میپرسد «خبر تازهای هست؟». اپ سفارش غذا را تصور کنید که هر سی ثانیه وضعیت سفارش را از سرور میگیرد تا کاربر ببیند آیا پیک راه افتاده یا نه. بیشتر این پرسوجوها پاسخ «هنوز نه» میگیرند و هیچ خبری حمل نمیکنند؛ یعنی ترافیک مفید، کسر کوچکی از کل درخواستهاست.
سادگی، بزرگترین فضیلت این الگو است: گیرنده کنترل کامل زمانبندی را دارد، به نشانی عمومی یا زیرساخت خاصی نیاز ندارد و پیادهسازیاش در چند ساعت انجام میشود. اما هزینهها هم واقعی است: خبر دیرتر از زمان رخداد میرسد و بار پرسوجوهای خالی، با بزرگشدن تعداد کاربران بهطور چشمگیر بالا میرود.
Webhook: فرستنده، خودش زنگ میزند
در Webhook، گیرنده یک نشانی عمومی برای فرستنده ثبت میکند و بهمحض وقوع رویداد، فرستنده با یک درخواست HTTP به همان نشانی، خبر را همراه جزئیات میفرستد. اینجا جهت ارتباط برعکس است: خبر از سمت منبع، به سمت مشتاق میآید. نتیجه، فوریت تقریباً کامل و حذف درخواستهای بیحاصل است؛ هر تماس، حامل یک رویداد واقعی است.
بهای این فوریت، مسئولیت است: نشانی گیرنده باید در دسترس و عمومی باشد، باید تأیید شود درخواست واقعاً از فرستنده معتبر آمده است — معمولاً با امضای رمزنگاریشده روی محتوا — و باید برای تکرارِ ارسال آماده بود، چون فرستندههای جدی در صورت نبود پاسخ موفق، خبر را دوباره میفرستند و گیرنده ممکن است همان خبر را چند بار دریافت کند.
مقایسه در یک نگاه
| معیار | Polling | Webhook |
|---|---|---|
| آغازگر ارتباط | گیرنده، در بازههای زمانی | فرستنده، لحظه رخداد |
| تأخیر رسیدن خبر | تا اندازه بازه زمانی | تقریباً آنی |
| درخواستهای بیحاصل | زیاد؛ بیشتر پرسوجوها خالیاند | تقریباً هیچ؛ هر تماس حامل رویداد است |
| الزامات زیرساختی | حداقل؛ گیرنده فعال میپرسد | نشانی عمومی و پایدار برای دریافت |
| اعتبارسنجی | کنترل سمت خود گیرنده | لازم؛ تأیید امضای فرستنده در هر تماس |
| رفتار در اختلال | پرسش بعدی دوباره انجام میشود | نیازمند صف تلاش مجدد و ثبت رخداد |
| سناریوی مناسب | تغییرهای کند و ابزارهای داخلی | خبررسانی فوری مانند نتیجه پرداخت یا تیکت جدید |
پیامد: وقتی الگوی غلط را انتخاب میکنیم
Polling برای رویدادهای کمیاب و حساس به تأخیر، هزینه پنهان دارد؛ صفحهای که هر پنج ثانیه وضعیت پرداخت را میپرسد، برای خبری که بهندرت میآید ترافیک دائمی میسازد و در روزهای پررفتوآمد، خودش به نقطه ضعف بار تبدیل میشود. برعکس، اتکای صرف به Webhook برای گیرندههای بیثبات، خبری گم میکند: اگر در لحظه ارسال، سرویس گیرنده از دسترس خارج باشد و سازوکار تلاش مجدد نباشد، آن رویداد دیگر برنمیگردد.
خبری که نمیرسد، دیده نمیشود؛ نظارت بر تحویل را بخشی از طراحی کنید، نه پیوست بعدی.
مثال کاربردی: اپ سفارش غذا
فرض کنید اپ سفارش غذا میسازید. برای نمایش وضعیت به مشتری، ترکیب معقول چنین است: اپ برای وضعیتهای درونسازمانی مانند آمادهسازی و ارسال از Polling با بازه منطقی استفاده میکند، چون کنترل کامل در دست خودتان است و تغییرها کند است؛ اما برای نتیجه پرداخت، درگاه با Webhook خبر میدهد: لحظهای که پرداخت قطعی میشود، درگاه به نشانی فروشگاه درخواستی همراه جزئیات تراکنش میفرستد، فروشگاه سفارش را تأیید و آشپزخانه را بیدار میکند.
در این ترکیب، هر الگو جایی نشسته که مزیتش بیشینه و هزینهاش کمینه است. نکته ظریف این است که دریافت Webhook باید مثل هر عملیات حساس، در برابر تکرار مقاوم باشد؛ چون پیام پرداخت موفق ممکن است دو بار برسد و پاسخ به آن دو بار، نباید دو سفارش بسازد.
راهکار: چگونه الگو را انتخاب و اجرا کنیم؟
- اگر خبر فوری است و منبعش بیرون از کنترل شماست — درگاه پرداخت، سرویس پیامرسانی، پلتفرم فروش — Webhook را با تأیید امضا و پاسخ سریع بپذیرید.
- اگر کنترل کامل دارید و تغییرها کند است، Polling با بازه منطقی ساده و مقاوم است؛ برای کاهش بار، پاسخهای تکراری را قابل ذخیره موقت (Cache) کنید.
- برای حالتهای میانی، الگوهای واسط هم هست: Polling طولانی (Long Polling) که اتصال را باز نگه میدارد تا خبر برسد، و خانواده اتصال دائمی مانند WebSocket برای جریانهای زنده.
- در هر دو الگو، ثبت رخداد و نظارت را فراموش نکنید؛ نرخ موفقیت تحویل Webhook و نسبت پرسوجوهای خالی در Polling، شاخصهای سلامت این اتصالاند.
کاربرد عملی
پیش از انتخاب، سه چیز را روی کاغذ بنویسید: فوریت خبر چقدر است، منبع خبر در کنترل شماست یا نه، و گیرنده چقدر پایدار است. اگر خبر باید در ثانیههای اول برسد و منبع بیرونی است، Webhook با صف تلاش مجدد و تأیید امضا انتخاب کنید. اگر کنترل کامل دارید و تأخیر چند ثانیهای قابل تحمل است، Polling سادهتر و ارزانتر است. در بیشتر محصولهای واقعی، پاسخ نهایی ترکیبی است؛ مهم این است که هر رویداد با الگوی مناسب خودش سفر کند، نه با سلیقه روز اول پروژه.
نکات کلیدی این مقاله
- Polling یعنی پرسیدنِ دورهای؛ ساده و قابل کنترل، اما پر از درخواست بیحاصل و محدود به تأخیر بازه زمانی.
- Webhook یعنی خبررسانی رویدادمحور؛ فوری و کمهزینه، اما نیازمند نشانی عمومی، تأیید فرستنده و مقاومت در برابر تکرار.
- انتخاب درست تابع فوریت خبر، کنترل شما بر منبع و ثبات گیرنده است، نه ترجیح شخصی تیم.
- ترکیب الگوها در یک محصول واقعی نهتنها مجاز، بلکه معمول است؛ هر رویداد با الگوی مناسبش.
- برای Webhook، پاسخ سریع، تأیید امضا و صف تلاش مجدد سه ستون اطمیناناند.
سوالات متداول
آیا Webhook جایگزین کامل Polling است؟
نه. Webhook زمانی بهترین است که فرستنده توان ارسال رویداد داشته باشد و گیرنده نشانی عمومی پایداری داشته باشد. در محیطهای داخلی، ابزارهای بدون پشتیبانی Webhook یا گیرندههای ناپایدار، Polling همچنان انتخاب ساده و مطمئنی است.
اگر در لحظه ارسال Webhook سرویس من پایین باشد چه میشود؟
فرستندههای استاندارد، ارسال را دوباره با فاصلههای زمانی تکرار میکنند تا پاسخ موفق بگیرند. وظیفه گیرنده این است که این تکرارها را بدون اثر جانبی مدیریت کند و برای رخدادهایی که واقعاً از دست رفتهاند، راه بازیابی مانند شمارش تطبیقی داشته باشد.
برای شروع، از کدام الگو بروم؟
اگر در فاز اولیه هستید و خبر در کنترل خودتان است، با Polling شروع کنید و زمان را صرف ثبات محصول کنید؛ هر جا خبر فوری و منبع بیرونی شد، آنجا به Webhook مهاجرت کنید. این مسیر، ریسک فنی را کم و یادگیری را تدریجی میکند.
