القرارات المعمارية التي تحدد ما إذا كانت البنية التحتية للمدفوعات تنجو من حمل الوكلاء على نطاق واسع

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

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

ملف تعريف الحمل لمنصة يقودها الوكلاء لا يشبه تطبيق SaaS إطلاقاً

تتبع أحجام مدفوعات SaaS التقليدية منحنيات يمكن التنبؤ بها. ذروات يومية، دورات أسبوعية، ارتفاعات عرضية مدفوعة بالتسويق. يعد تخطيط السعة حول تلك المنحنيات مشكلة معروفة مع مجموعة معروفة من الإجابات، وتم ضبط معظم البنية التحتية للمدفوعات وفقًا لهذا الملف الشخصي.

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

الاختلاف الثاني هو غياب التوقيت الطبيعي. يتعب البشر، يأخذون فترات راحة، يصلون إلى حدود المعدل ضمنيًا. لا يفعل الوكلاء ذلك. سوف يشبعون أي مسار يُمنح لهم، وسوف يستمرون في إعادة المحاولة عندما يفشل شيء ما لأن منطق إعادة المحاولة هو أسهل سلوك يمكن كتابته وأصعب سلوك يُكتب بشكل صحيح. البنية التحتية للمدفوعات التي تعتمد على تحديد المعدل الطبيعي من السلوك البشري تتعطل على الفور.

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

تصميم التفرد هو أول ما ينهار

تُعامل مفاتيح التفرد عادةً كميزة تحقق. تدعمها واجهة برمجة التطبيقات (API)، وتنشئها حزمة تطوير البرامج (SDK)، والافتراض هو أن عمليات إعادة المحاولة ستكون آمنة لأن المفتاح تم تمريره. تحت حمل الوكلاء، تنهار هذه الفرضية بسرعة، ويصبح تصميم التفرد أحد القرارات المعمارية ذات التأثير الأكبر في المكدس بأكمله.

أول نمط فشل هو النطاق. معظم تطبيقات التفرد تحدد نطاق المفتاح لنقطة نهاية واحدة، مما يعني أن عملية إعادة محاولة تتبع مسارًا برمجيًا مختلفًا قليلاً تنتج مفتاحًا مختلفًا ورسومًا مكررة. الوكلاء عرضة بشكل خاص لإعادة المحاولة عبر مسارات برمجية بديلة لأن منطق اتخاذ القرار لديهم يتضمن مسارات احتياطية، وقد لا يحافظ المسار الاحتياطي على المفتاح الأصلي.

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

نموذج الفشل الثالث هو الحتمية. يجب أن يكون المفتاح مستنتجًا من نية الوكيل، وليس من حمولة الطلب، لأنه قد تتم إعادة تسلسل الحمولة بشكل مختلف عبر عمليات إعادة المحاولة. مفتاح مستنتج من معرف مهمة الوكيل والإجراء المنطقي مستقر. المفتاح المستنتج من نص JSON ليس كذلك، لأن الترتيب الدقيق للحقول أو معالجة القيم الافتراضية ستنتج تباينًا عبر المحاولات.

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

عواصف إعادة المحاولة هي خاصية من خصائص البنية المعمارية، وليست من خصائص الوكيل

العلاج الغريزي عند تسبب عمليات إعادة المحاولة في مشاكل هو النظر إلى الوكيل وتشديد سياسته الخاصة بإعادة المحاولة. نادرًا ما يكون هذا هو المكان الصحيح للتدخل. عواصف إعادة المحاولة هي خاصية ناشئة عن البنية المعمارية، والعلاج الدائم الوحيد هو استيعابها على مستوى البنية التحتية بدلاً من توقع أن يقوم كل وكيل بإعادة المحاولة بلطف.

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

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

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

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

التسوية هي المكان الذي تصمد فيه البنية المعمارية أو تنهار

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

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

القرار الثاني هو شكل مصدر الحقيقة. المعماريات التي تعامل معالج الدفع كمصدر للحقيقة ودفتر الأستاذ الخاص بالمنصة كعمل مشتق تعمل بشكل جيد حتى يكسر انقطاع المعالج أو الويب هوك المتأخر هذا الافتراض. المعماريات التي تحتفظ بدفتر أستاذ داخلي موثوق وتعامل المعالج كإشارة واحدة من عدة إشارات تنجو من تلك الأحداث دون فقدان البيانات. يجب تصميم دفتر الأستاذ الداخلي لاستيعاب الأحداث غير المرتبة والمتكررة والمتناقضة أحيانًا من المسارات الأولية.

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

القرار الرابع هو الحبيبية. التسوية التي تعمل على مستوى المعاملات تفوت التناقضات المنهجية التي تظهر فقط على مستوى الدفعة أو المستوى اليومي. التسوية التي تعمل فقط على المستوى اليومي تفوت المشكلات المتعلقة بالمعاملات الفردية التي تهم دعم العملاء الفردي. المعماريات التي تصمد على نطاق الوكيل تسوي في مستويات متعددة في وقت واحد، مع توفير المستويات الأعلى سياقًا للمستويات الأدنى.

معالجة الاستثناءات بدون تدخل بشري

تُعد معالجة الاستثناءات أصعب مشكلة معمارية في البنية التحتية للمدفوعات التي تعتمد على الوكلاء، لأن النموذج القياسي يفترض أن الإنسان سيقوم في النهاية بالفصل في الحالات الشاذة. يجعل حجم الوكلاء هذا النموذج غير قابل للتطبيق، ويتطلب استبداله نهجًا تدريجيًا متعمدًا لا يصعد إلا الاستثناءات التي تحتاج حقًا إلى حكم بشري.

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

المستوى الثاني هو الحل المساعد. تتطلب بعض الاستثناءات سياقًا إضافيًا ولكنها تتبع عددًا صغيرًا من الأنماط. تسمح المعماريات التي تدعم الحلول التي تعتمد على الوكلاء مع مخطط استثناءات منظم، بما في ذلك سبب الفشل، والسياق المحيط، وخيارات العلاج المتاحة، لوكيل آخر باتخاذ القرار بناءً على السياسة بدلاً من التصعيد إلى إنسان. هذه هي الطبقة التي تنجح فيها معظم البنية التحتية لمعالجة المدفوعات المستقلة أو تتوقف فيها.

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

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

العملات المتعددة والصرف الأجنبي في زمن استجابة الوكيل

تختلف القرارات المعمارية التي تحدد ما إذا كان دعم العملات المتعددة ينجو من حمل الوكيل عن تلك التي تهم العملات المتعددة التي يقودها الإنسان. يجعل حجم تحويلات العملات الأجنبية على نطاق الوكيل التحسين مصدر قلق معماري من الدرجة الأولى بدلاً من مشروع هادئ لفريق الخزانة.

الخيار الأول هو ما إذا كان سيتم التحويل عند المسار أو عند المنصة. التحويل عند المسار مريح ويمكن التنبؤ به ولكنه يدفع عمولة المسار على كل تحويل. يتطلب التحويل عند المنصة الاحتفاظ بأرصدة متعددة العملات وإدارة مخاطر سعر الصرف، ولكن توفير العمولة يتضاعف عبر الحجم بطرق تغير بشكل كبير اقتصاديات الوحدة. تنتقل معظم المنصات التي تدير حجم وكلاء جادًا في النهاية إلى التحويل على مستوى المنصة على الأقل لممراتها الأساسية.

الخيار الثاني هو استراتيجية التخزين المؤقت للأسعار. يتحرك الوكلاء بسرعة كبيرة جدًا لتحديث سعر الصرف من مصدر أساسي في كل معاملة، لكن الأسعار القديمة تنتج انحرافًا يتضاعف. النمط الذي يصمد هو ذاكرة التخزين المؤقت للأسعار متعددة المستويات مع فترة تحديث قصيرة للأزواج ذات الحجم الكبير وفترة أطول للذيل الطويل، مع معالجة صريحة للحظات التي يُعرف فيها أن السعر غير موثوق به.

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

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

الامتثال كطبقة معمارية بدلاً من تكوين

كان الامتثال يُعامل تاريخيًا كخطوة تكوين في نهاية عملية التكامل. اختر المسار المرخص، قم بتكوين تدفق KYC، اشحن. يعمل هذا النموذج عندما يكون البشر هم من ينشئون المعاملات ويكون الحجم منخفضًا بما يكفي لفريق الامتثال لمراجعة الحالات الشاذة. لا يعمل عندما ينشئ الوكلاء آلاف المعاملات في الدقيقة ويتناسب الذيل الطويل لاستثناءات الامتثال مع الحجم.

القرار المعماري هو ما إذا كان الامتثال يعيش كطبقة تمر من خلالها كل معاملة للوكيل، أو كتكوين على المسارات. المعماريات التي تصمد تعامل الامتثال كطبقة. فحص العقوبات، وفحوصات حداثة KYC وKYB، ومراقبة المعاملات، والقواعد التنظيمية الإقليمية كلها تعيش فوق المسارات ويتم فرضها باستمرار بغض النظر عن المزود الأساسي الذي يتعامل مع المعاملة.

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

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

يجب أن يسجل مسار المراجعة ليس فقط ما فعله الوكيل ولكن لماذا، بما في ذلك إصدار السياسة المطبقة، والقاعدة التي سمحت بالإجراء، والإجراءات البديلة التي تم رفضها. هذا العمق هو ما يجعل استفسارات التنظيم قابلة للتطبيق على نطاق الوكيل، وهو نوع القرار المعماري الذي يجب اتخاذه في البداية لأن تعديله لاحقًا مكلف للغاية.

كيف يبدو الصمود تحت حمولة الوكيل فعليًا

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

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

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

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

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

لماذا هذه الهندسة المعمارية هي الحل الحقيقي

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

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

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

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

حول TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) هي شركة هندسة مخاطر تنشر بنية تحتية للوكلاء الأذكياء عبر الأعمال من خلال ثلاث ركائز متكاملة: البنية التحتية للوكلاء، ومسارات الدفع غير التقليدية، ومحرك مشاريع كامل. بفضل 27 عامًا من الخبرة في المدفوعات والبرمجيات، تعمل TFSF عالميًا، وتخدم 21 قطاعًا منهجيًا بمنهجية نشر تستغرق 30 يومًا. تعرف على المزيد على https://tfsfventures.com

قم بإجراء تقييم الذكاء التشغيلي المجاني

قم بإجراء تقييم الذكاء التشغيلي المجاني. أجب عن بعض الأسئلة السريعة حول عملك. احصل على مخطط نشر مخصص للذكاء الاصطناعي خلال 24 إلى 48 ساعة يتضمن توصيات الوكلاء، والهندسة المعمارية، وخارطة طريق خاصة بعملياتك. لا توجد مكالمة مبيعات. لا التزام. فقط بيانات. ابدأ من https://tfsfventures.com/assessment

نُشرت أصلاً في https://tfsfventures.com/blog/the-architecture-decisions-that-determine-whether-payment-infrastructure-survives-agent

بقلم TFSF Ventures Research