تصميم الأنظمة الخلفية الحوارية حول مُهَل API Gateway

كل مهندس معماريات حوارية يتعلم الرقم ٢٩ في نهاية المطاف. مهلة التكامل التقليدية في API Gateway البالغة ٢٩ ثانية — وصبر القنوات الصوتية الأضيق منها — تعني أن بطء نظام إدارة الوثائق قد يجمّد المحادثة إلى ما بعد حدّ انتظار العميل. وقد أتاحت AWS لاحقًا رفع مهلة التكامل فوق ٢٩ ثانية لواجهات REST الإقليمية (مع مقايضات في معدلات الطلبات)، لكن درس التصميم باقٍ: يجب ألا تنتظر المحادثة نظامًا أساسيًا بطيئًا انتظارًا متزامنًا.

النمط الأول: أقرّ بالطلب ثم عاود الاتصال

للعمليات البطيئة فعلًا — كالتظهيرات وإصدار المستندات — أعد ردًا فوريًا بإقرار حواري، وسلّم العمل لمسار غير متزامن (SQS أو Step Functions)، ثم أبلغ عند الإنجاز: برسالة صادرة، أو بحالة يفحصها الروبوت حين يسأل العميل. يتقبل العملاء عبارة «بدأتُ التنفيذ وستصلك رسالة خلال دقائق» أفضل بكثير من الصمت.

النمط الثاني: خزّن حزمة عمل الجلسة مؤقتًا

معظم أدوار المحادثة لا تحتاج قراءة حية من النظام الأساسي. ذاكرة مؤقتة قصيرة الأجل في DynamoDB لحزمة عمل الجلسة — كملخص الوثيقة المجلوب مرة واحدة عند التحقق — تحوّل خمسة استدعاءات بطيئة إلى واحد، وتجعل كل دور تالٍ فوريًا في إحساسه.

النمط الثالث: ضع ميزانية زمنية لكل خطوة

حدد ميزانيات مُهَل صريحة لكل خطوة (الروبوت ← المنسق ← الموائم ← النظام الأساسي) بحيث يبقى مجموعها مريحًا دون صبر القناة، مع قواطع دارة تتدهور بلطف إلى «دعني أوصلك بموظف» بدل رسالة خطأ تقنية. في الصوت، استهدف زمن دور كامل دون ثلاث ثوانٍ، واملأ الانتظارات الحتمية بكلام يفيد بالتقدم.

لا شيء من هذا غريب؛ إنه الفرق بين روبوت يُحسن العرض التجريبي وآخر يصمد عند لقاء الحاسوب المركزي.