كيفية تنفيذ منطق الدفع باستخدام Vercel Workflows بدون طوابير خارجية

فصل الخطوات لبيئات الإنتاج

عند التعامل مع الدوال عديمة الخادم (Serverless Functions)، ستواجه غالباً عائق المهلة الزمنية للتنفيذ. تقوم Vercel Workflows بحل هذه المشكلة عن طريق تحويل الدوال غير المتزامنة إلى عمليات قادرة على حفظ الحالة. المفتاح هنا هو إزالة العناصر غير المؤكدة مثل الكتابة في قاعدة البيانات أو الدوال العشوائية من داخل دالة المنسق (Orchestrator). يجب حصر جميع الآثار الجانبية (Side effects) داخل بلوك step.run لضمان عدم ارتباك النظام.

أعلن عن use workflow في الدالة التي تتحكم في المنطق بالكامل وقم بإدارة التدفق فقط. أما استدعاءات API الفعلية أو عمليات قاعدة البيانات، فحددها كخطوات مستقلة. عند الانتقال إلى الخطوة التالية، اختر فقط البيانات الضرورية لتمريرها لتقليل تكاليف تخزين السجلات. بفضل هذا الهيكل، حتى لو فشلت العملية في المنتصف، فلن تحتاج للبدء من الصفر؛ يمكنك ببساطة الاستئناف من نقطة التوقف.

منطق التماثل (Idempotency) لمنع تكرار الدفع

في الأنظمة الموزعة، قد تؤدي أخطاء الشبكة إلى تنفيذ نفس الخطوة مرتين، وهو أمر كارثي في أنظمة الدفع. توفر Vercel Workflows معرف stepId فريد لكل خطوة. عند الربط مع خدمات مثل Toss Payments أو Stripe، يمكنك استخدام هذا المعرف كمفتاح تماثل (Idempotency Key) لمنع حوادث الدفع المزدوج.

اعتمد نمطاً في الكود للتحقق مما إذا كانت البيانات قد تمت معالجتها بالفعل قبل الكتابة. يمكنك تخصيص المعرف المستخرج عبر getStepMetadata() لترويسة (Header) طلب الخدمة الخارجية. صمم النظام ليعيد النتيجة فوراً إذا كانت المعاملة قد تمت معالجتها مسبقاً. هذا الهيكل يقلل من استدعاءات API غير الضرورية ويوفر أكثر من 20% من تكاليف البنية التحتية.

إدارة المهام طويلة الأمد بدون مهلة زمنية

عادةً ما تتوقف دوال Vercel Serverless بعد دقيقة إلى 15 دقيقة. ولكن باستخدام step.sleep، يمكنك تنفيذ مهام مجدولة تستغرق أياماً بسهولة. عند تنفيذ هذه الدالة، يتم تسجيل حالة سير العمل في وحدة التخزين وتتوقف الدالة فوراً، ولا يتم احتساب تكاليف حوسبة أثناء فترة الانتظار.

على سبيل المثال، إذا كنت بحاجة لإرسال بريد إلكتروني لاستطلاع الرأي بعد 3 أيام من إتمام الدفع، يكفي سطر واحد: await step.sleep('3 days'). لا داعي لإدارة Crontab أو جدولة منفصلة، مما يقلل وقت التشغيل بمقدار ساعتين أسبوعياً ويلغي تكاليف تشغيل الخادم على مدار الساعة.

التحقق من سير العمل محلياً

تكرار عملية النشر والتعديل يقلل من سرعة التطوير. باستخدام ميزات Vercel CLI، يمكنك الاختبار محلياً دون الرفع إلى السحابة. إذا كنت بحاجة لاستقبال Webhooks خارجية، استخدم أدوات مثل ngrok لفتح منفذ محلي للخارج.

قم بتشغيل vercel dev وتسجيل عنوان URL الناتج من ngrok في إعدادات Stripe Webhook، وسيبدأ الكود المحلي باستقبال الأحداث الخارجية في الوقت الفعلي. يمكنك التحقق من سيناريوهات الفشل قبل النشر، مما يضاعف سرعة التطوير ويقلل الوقت الضائع في أخطاء إعدادات متغيرات البيئة.

سياسة إعادة المحاولة القائمة على التراجع الأسي

قد تؤدي إعادة المحاولة اللانهائية بسبب قيود سرعة API أو أعطال الشبكة المؤقتة إلى انفجار في التكاليف. يجب التعامل بشكل مختلف حسب نوع الخطأ؛ فالأخطاء الدائمة مثل فشل المصادقة يجب إيقافها فوراً، بينما الأخطاء المؤقتة مثل مشاكل الشبكة يجب إعادة محاولتها بعد فترة.

قم بتطبيق صيغة التراجع الأسي (Exponential Backoff) لزيادة فترات إعادة المحاولة تدريجياً:

$$Interval = InitialDelay \times 2^{Attempt}$$

حدد maxRetries: 3 في دالة step.run لتقييد الحد الأقصى للمحاولات. سيتعافى النظام تلقائياً مما يزيد من توفر الخدمة، ويمنع الفواتير الباهظة الناتجة عن الحلقات المفرغة.

تكاليف التشغيل وكفاءة البنية التحتية

توفر Vercel Workflows في خطة Pro سعة 50,000 خطوة تنفيذ بشكل أساسي. عند التجاوز، تبلغ الرسوم حوالي $2.50 لكل 100,000 خطوة. تكاليف التخزين أثناء الانتظار الطويل رخيصة جداً وتبلغ $0.00069 لكل GB-Hour.

الفئة	الكمية المضمنة (Hobby/Pro)	رسوم التجاوز
Workflow Steps	50,000 خطوة	$2.50 لكل 100,000 خطوة
Workflow Storage	720 GB-Hours	$0.00069 لكل GB-Hour
Serverless Function	1,000 GB-Hours	$0.60 لكل GB-Hour

هذا الحل اقتصادي للغاية مقارنة بجهد بناء وإدارة طوابير رسائل (Message Queues) معقدة بنفسك. بدمج ضمان التماثل والتراجع الأسي بشكل صحيح، يمكنك تحقيق موثوقية بمستوى الإنتاج دون عبء إدارة البنية التحتية. بالنسبة للمطور المستقل الذي يريد التركيز على منطق الأعمال فقط، لا يوجد خيار أكثر منطقية من هذا.