بنينا منصة تداول من الصفر. إليك ما تطلّبه ذلك.

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

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

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

الرسم البياني للسعر الذي يظهر متأخرًا ثانية واحدة أمر مزعج. أما الإيداع الذي يُقيَّد مرتين فحادثة. وأكبر فرق بين النسخة التجريبية والمنصة الحقيقية أن كل مسار تسلكه الأموال مصمَّم وفق معيار مختلف عن كل ما سواه.

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

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

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

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

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

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

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

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