حين يأتيني عميل يسأل عن البيانات الحية، أول سؤال أطرحه ليس "webhook أم polling"، بل "كم شخص سيستخدم هذا في نفس الوقت؟" و"كم مرة تتوقع أن تتغير البيانات في الساعة الواحدة؟" لأن الإجابة تحسم الخيار كلياً.
ما هما webhooks و polling حقاً
دعني أبدأ بالوضوح الصريح: webhook هي طلب يرسله السيرفر إليك عندما تحدث حادثة. polling هي أنت تسأل السيرفر كل بضع ثوانٍ: "حصل شيء جديد؟". الفارق يبدو بسيطاً، لكنه يشتعل بسرعة حين تدخل الأرقام الحقيقية.
في تطبيق لإدارة متجر إلكتروني تابع لعميل من دبي، كنا نراقب آخر 50 طلب شراء. مع polling كل 5 ثوانٍ على 100 مستخدم متصل، كنا نرسل 20 طلب قاعدة بيانات كل ثانية. مع webhook، رسالة واحدة حين يأتي طلب فقط. الفارق؟ فاتورة الخادم انخفضت من 180 دينار شهرياً إلى 45.
أيهما يكلفك أقل فعلاً
هنا حيث يخطئ معظم الناس: يفكرون بـ "webhook أرخص" بلا أرقام حقيقية. لا. الواقع أعقد.
Polling
تكلفة البناء: منخفضة جداً — حلقة بسيطة كل N ثانية.
تكلفة التشغيل: تنمو مع عدد المستخدمين والتكرار. 500 مستخدم × كل 10 ثوانٍ = 50 طلب/ثانية. عند 1000 مستخدم تشعر بالضغط على قاعدة البيانات.
Webhooks
تكلفة البناء: عالية — تحتاج قائمة انتظار (queue)، معالج أخطاء قوي، إعادة محاولة. شهر من العمل على الأقل.
تكلفة التشغيل: محدودة — تدفع فقط حين يحدث شيء فعلي.
النتيجة
Polling أرخص حتى ~300 مستخدم متصل في نفس الوقت. بعدها webhooks تقترب من التعادل ثم تربح. لكن أدوات polling المُدارة (مثل AWS SQS) تغير المعادلة كلياً.
من تجربتي في قيادة مشاريع في الكويت والخليج، معظم الشركات التي اختارت webhook بلا أن تحتاجها قضت أسابيع تبني نظام retry معقد، وعندما حدث أول انقطاع في الشبكة خسرت بيانات. عميل في السعودية كان عنده متجر مع 180 مستخدم متصل فقط اختار webhook "لأنها أحدث"، وانتهى به الحال بـ AWS Lambda مرتفعة التكلفة بلا سبب حقيقي.
معايير القرار التي تعمل
بدلاً من نقاشات فلسفية، إليك الشروط:
| الحالة | اختر | السبب |
|---|---|---|
| أقل من 200 مستخدم متصل، تحديثات نادرة | Polling | لا تحتاج التعقيد. كل 15-30 ثانية كافي تماماً |
| 500+ مستخدم متصل، تحديثات متكررة | Webhooks | الضغط على قاعدة البيانات سيكسرك في poll كل 5 ثوان |
| نقاط دفع حية (Telr، 2Checkout) | Webhooks إجباري | لا بديل — المدفوعات تحتاج فوراً. لا يمكنك انتظار poll |
| لا تريد قاعدة بيانات قوية جداً | Webhooks | تخفض الضغط بـ 70% تقريباً |
| بيئة محدودة الموارد (shared hosting) | Polling محدود | webhooks تحتاج معالج قوي. polling أسهل على الموارد الضعيفة |
واقعياً؟ معظم شركات الكويت والإمارات التي أعرفها في النطاق 100-500 مستخدم تكون polling الخيار الأصح. لكن معظمهم يختارون webhook "لأنها تبدو احترافية أكثر"، ثم يدفعون ثمن إضافي بلا فائدة.
رأيت هذا الخطأ بالذات يُغرق مشاريع كانت ممولة جيداً
التحذير: قائمة الانتظار المنسية
حين تختار webhooks، تحتاج قائمة انتظار (Redis أو RabbitMQ أو AWS SQS) بيننا وبين معالجك. بلا ذلك، إن حدث spike من 100 webhook في 10 ثوانٍ، ستفقد البيانات. رأيت مشروع في البحرين انقطعت قائمة الانتظار عنده لمدة 3 ساعات ولم يلاحظ إلا بعد 3 أيام. فقد 2000 تنبيه عميل. ساعات من صيانة الأخطاء بعدها.
الحالات اللي بتحتاج webhook فعلاً
دعني أكون صريحاً: معظم التطبيقات لا تحتاجها. لكن هذه الحالات فعلاً:
شبكات الدفع. عندما يكمل عميلك الدفع على Telr أو 2Checkout، لا يمكنك polling: تحتاج تنبيه فوري قبل حتى ما يرجع العميل للموقع. webhook هي الطريقة الوحيدة هنا.
إدارة المخزون الفورية. محل في الكويت عنده 200 منتج في قاعدة بيانات مركزية، وآخر 50 ردود على Telegram و Instagram و WhatsApp. حين ينتهي المخزون، تحتاج كل قنوات بتعرف في ثانيتين. polling هنا ستضطرك لكل دقيقة تقريباً، و webhooks أفضل بـ 100 مرة.
الرسائل الفورية والإشعارات. إن كان لديك تطبيق chat أو نظام تنبيهات متقدم، polling ستكون حجر الرحى. webhooks تخلصك من التأخير.
التكامل مع أنظمة خارجية مباشرة. مثل Slack integration أو CRM خارجي — إذا كنت تريد متزامن فوري، webhook هو الخيار الوحيد.
بخلاف هذا؟ polling كافي، وأرخص بكثير.
النسخة العملية: كيف تختار الآن
إليك الخطوات التي أتبعها في كل مشروع:
اسأل عن الأرقام الحقيقية أولاً
كم مستخدم متصل في ذروة الاستخدام؟ كم تغيير بيانات توقع في الساعة؟ أين المشكلة الفعلية — تأخير أم ضغط؟
ابدأ بـ polling بسيطة
إلا إذا كنت متأكداً 100% أنك تحتاج webhook — ابدأ بـ polling. أرخص بناء، أقل تعقيد.
راقب الأداء الفعلي
بعد أسبوعين، شُف استخدام قاعدة البيانات والخادم. إذا كانت الاستعلامات تأخذ 30% من موارد الخادم، فأنت تحتاج webhook. إذا كانت 5%، polling تمام.
إذا لزم الأمر، انتقل إلى webhooks
لكن بناء قوي: استخدم AWS SQS أو Kafka أو حتى Redis. بلا قائمة انتظار قوية، لا تذهب للـ webhooks.
أداة تقرر لك بسرعة
أستخدم هذا السؤال البسيط مع العملاء:
"إذا انقطع الإنترنت عندك لمدة ساعة، ثم عاد، كم رسالة عميل ستفقد مقبول؟"
إذا الإجابة "صفر — كل شيء يجب أن يصل"، فأنت تحتاج webhook + قائمة انتظار قوية. إذا الإجابة "ممكن نفقد 100-200 رسالة"، polling كافي تماماً.
معظم الأوقات؟ الإجابة الثانية. والتكلفة تنخفض من 5000 دينار شهرياً إلى 800.
التكاليف الحقيقية في 2026
إذا كنت تستخدم AWS:
- Polling مع RDS: ~40-80 دينار شهري للقاعدة (صغيرة)، + Lambda free tier للـ polling
- Webhooks مع SQS + Lambda: ~120-200 دينار شهري (أعلى بسبب SQS + more Lambda invocations)
لكن إذا كنت على shared hosting (Hostinger، GoDaddy):
- Polling: تقريباً مجاني — حلقة بسيطة في cron
- Webhooks: تحتاج upgraded plan لأنك تحتاج معالج قوي — ربما 20-30 دينار إضافي
من بحثي في تسعير AWS SQS، أول مليون رسالة مجاني، لكن بعده تدفع 0.40 دولار لكل مليون. إذا كنت تتوقع 5 مليون رسالة شهرياً (webhook من شبكات دفع + مستخدمين)، تكلفة SQS نفسها 2 دولار.
الخطأ الوحيد اللي بتندم عليه
بناء webhooks بدون إدارة أخطاء
معظم المشاريع التي شُفت تفشل في webhooks ليست لأن الفكرة خاطئة — لأن بناء الأخطاء كان ضعيفاً. webhook تفشل: شبكة تقطع، معالج يسقط، ميل يخطئ. إذا بنيت webhook بدون retry logic مع exponential backoff، و monitoring، ستفقد بيانات حتماً. هذا أكثر بحاجة يقدر تجاهله أحد.
الخلاصة التطبيقية
أختم بالنقطة العملية:
Polling هي الخيار الآمن 90% من الحالات. بسيطة، رخيصة، وتعمل. Webhooks احتفظ بها للحالات التي فعلاً تحتاج فوراً (دفع، مخزون حرج، رسائل مباشرة). بلا أرقام حقيقية؟ ابدأ بـ polling. بعد شهر من الضغط الفعلي، قرر.
أخطأت معك هنا الخطأ الوحيد: بناء webhook بدون فهم كم مستخدم فعلاً وكم بيانات فعلاً. اسأل الأسئلة أولاً، بنّي ثانياً.