عبارة «غير احتجازي» غالبًا ما تكون كلمة تسويقية. لكنها إذا استُخدمت بدقة تصبح قيدًا معماريًا، والقيود من هذا النوع مثيرة للاهتمام لأنها تحذف عملًا بدلًا من أن تضيفه.
يحتاج بوت التداول إلى وضع الأوامر نيابةً عنك. وتتيح المنصات ذلك عبر مفاتيح API، وتحمل مفاتيح API نطاقات صلاحيات: القراءة، والتداول، وفي معظم المنصات السحب أيضًا. لذا فإن السؤال التصميمي ليس ما إذا كنا سنطلب صلاحيات. بل أي الصلاحيات نطلب، وماذا نفعل حين نحصل على أكثر مما طلبنا.
أهم النقاط
- الوعد بعدم استخدام صلاحية ما أضعف من عدم امتلاكها أصلًا. نحن نرفض المفاتيح التي تحمل صلاحية السحب بدلًا من قبولها وتجاهلها.
- الرفض ضمانة أقوى من الثقة، لأنه لا يعتمد على صحة شفرتنا البرمجية أو نزاهة فريقنا.
- إذا كان تدفق الاتصال يكتب في حساب المستخدم، فيجب أن تأتي تلك الكتابات بعد قرار القبول لا قبله. وإلا فإنك تغيّر إعدادات شخص ما في طريقك إلى إخباره بالرفض.
- عدم الاحتفاظ بالأموال يحذف فئة كاملة من المشكلات الصعبة: لا سجل احتجاز، ولا تسوية، ولا طابور سحب.
- ما يحل محلها أضيق وأحدّ: يجب أن يكون نظامك صحيحًا في الزمن الحقيقي، لأنه لا يستطيع أبدًا التراجع عن أي شيء.
1. رفض الصلاحية أفضل من الوعد بعدم استخدامها
التنفيذ البديهي هو أن نطلب من المستخدمين مفتاحًا بنطاقي القراءة والتداول، وألا نستدعي نقاط نهاية السحب أبدًا. معظم القطاع يفعل ذلك، وهو ليس أمرًا غير معقول.
نحن نفعل شيئًا أكثر صرامة. إذا وصل مفتاح يحمل صلاحية السحب، فإنه يُرفض. ويرى المستخدم رسالة تخبره بالضبط بما يجب فعله:
مفتاح API هذا لديه صلاحية السحب مفعّلة. Freya لا تسحب الأموال أبدًا، لذا لا تُقبل المفاتيح التي تحمل تلك الصلاحية. الرجاء إنشاء مفتاح بصلاحيتي القراءة والتداول فقط.
تنطبق القاعدة نفسها على المنصات الثلاث التي ندعمها. لا يوجد تجاوز ولا استثناء إداري.
للوهلة الأولى يبدو هذا احتكاكًا لا مبرر له. فالمفتاح كان سيعمل. والمستخدم بذل بعض الجهد في إنشائه. ورفضه يعني إعادته إلى المنصة لإنشاء مفتاح آخر.
السبب هو أن التصميمين يقطعان وعدين مختلفين، والفرق لا يظهر إلا في أسوأ أيامك.
- عبارة «نحن لا نستدعي نقاط نهاية السحب أبدًا» ادعاء عن سلوكنا. وهو يصمد ما دامت شفرتنا البرمجية صحيحة، واعتمادياتنا نظيفة، وكل من يملك صلاحية النشر نزيهًا. وهذه أمور من المعقول توقعها. لكنها ليست أمورًا يستطيع المستخدم التحقق منها.
- عبارة «المفتاح لا يستطيع السحب» ادعاء عن المفتاح. وهو يصمد بغض النظر عما تفعله شفرتنا، لأن المنصة تفرضه، ويستطيع المستخدم أن يؤكده بنفسه في إعدادات منصته الخاصة.
الثاني طلب أضعف وضمانة أقوى. فضّل التصاميم التي تُفرَض خاصية أمانها من قبل جهة غير جهتك، خاصة حين لا يملك المستخدم أي وسيلة لتدقيق جانبك.
وهناك فائدة أصغر تهم في الممارسة العملية: إنها تجعل نمط الفشل صاخبًا. فالمفتاح ذو النطاق الزائد يُكتشف عند وقت الاتصال، أمام مستخدم منهمك في الإعداد فعليًا ويستطيع إصلاحه في دقيقة. أما البديل فهو أن يبقى المفتاح المفرط الصلاحيات يعمل بلا مشكلات ظاهرة، ولا يتعلم أحد شيئًا حتى تقع الكارثة.
2. قل «لا» قبل أن تمس أي شيء
هذه هي التفصيلة التي أودّ أكثر من غيرها أن يأخذها مهندس آخر عني، لأنها سهلة الخطأ وشبه غير مرئية حين تخطئ فيها.
توصيل منصة ليس عملية قراءة محضة. فبحسب المنصة، قد يتطلب إيصال حساب إلى حالة قابلة للعمل الكتابة فيه: تعديل وضع الحساب، وضبط وضع المركز، وما إلى ذلك. هذه خطوات مشروعة تحدث ضمن الإعداد.
الآن تأمل الترتيب. إذا حدث فحص الصلاحية بعد تلك الكتابات، فإن المفتاح المرفوض يترك أثرًا رغم رفضه. المستخدم سلّمك بيانات اعتماد، فعدّلت إعدادات في حسابه، ثم أخبرته بالرفض. ومن جانبه، لا شيء يفسّر لماذا صار إعداد منصته مختلفًا عمّا تركه عليه.
لذا فالقاعدة التي استقررنا عليها: يجب أن تترك بيانات الاعتماد المرفوضة حساب المستخدم كما وُجد بالضبط. أي خطوة تكتب تنتمي إلى ما بعد قرار القبول، لا قبله أبدًا. يجب أن يكون الرفض قابلًا للوصول دون آثار جانبية.
هذا في صورته المعمّمة مجرد تفكير معاملاتي مطبّق على نظام شخص آخر. لا تستطيع التراجع عن كتابة في حساب طرف ثالث، فيكون الترتيب حمايتك الوحيدة. حين لا تستطيع التراجع، رتّب بعناية.
ملاحظة تنفيذية واحدة أنقذتنا من فئة كاملة من العلل: يُعبَّر عن الرفض على هيئة نتيجة غير صالحة بدلًا من علامة خاصة، بحيث يتعامل معه كل مسار يستهلك نتيجة تحقق دون أن يعرف بوجوده أصلًا. لدينا تدفقا اتصال، وكلاهما يرث الرفض نفسه لأن أيًّا منهما لم يكن مضطرًا لتذكّر السؤال عنه. ترميز قاعدة في نوع يقرؤه كل المستهلكين بالفعل أفضل من توثيقها والأمل بالخير.
3. ما الذي يحذفه القيد
هنا يتحول الأمر إلى صفقة رابحة بوضوح.
لا تغادر الأموال حساب المستخدم على المنصة أبدًا. تتداول البوتات بمفاتيح القراءة والتداول، ويبقى الرصيد حيث بدأ. وما يترتب على ذلك قائمة طويلة من الأشياء التي ببساطة لا وجود لها في نظامنا:
- لا سجل احتجاز، وبالتالي لا تسوية بين رصيد داخلي وآخر خارجي
- لا طابور سحب، ولا سير عمل موافقات، ولا حدود يومية على رأس مال التداول
- لا تقسيم بين محفظة ساخنة وباردة لذلك الرأس مال، ولا إدارة مفاتيح حوله
- لا سؤال عمّا يحدث لأموال المستخدم إذا اختفت الشركة
كل واحدة من هذه المسائل نظام فرعي كامل في منتج احتجازي، وكل منها موضع قد تضيع فيه الأموال. وهي غائبة هنا لا لأننا حللناها، بل لأننا لم نتحمّل قط الشيء الذي يخلقها.
لكني أريد الدقة بدلًا من التعميم: هذا ينطبق على رأس مال التداول. أما أرصدة المنصة المستخدمة للاشتراكات فمسألة منفصلة لها معالجتها الخاصة. الخاصية غير الاحتجازية تتعلق بالمال الذي يتداول، وهو المال الأهم.
4. ما الذي لا يصلحه
القيد الذي يزيل المشكلات يزيل كذلك الأدوات التي كنت ستستخدمها لإصلاح الأخطاء، ومن الجدير أن نكون صادقين بشأن ذلك.
الصفقات نهائية. مع الاحتجاز، يمكن مبدئيًا عكس تحويل داخلي. أما الأمر المنفَّذ على حساب منصة شخص آخر فلا يمكن عكسه. ينتقل كل الثقل الهندسي إلى الصحة قبل مغادرة الطلب، بدلًا من التسوية بعد وصوله. وهذا انضباط أصعب مما يبدو، وهو سبب انصباب جزء كبير من عملنا على التحقق والدقة والتكرارية الآمنة (idempotency).
صلاحية التداول تبقى صلاحية حقيقية. المفتاح المسرَّب بصلاحيتي القراءة والتداول لا يستطيع تفريغ حساب إلى عنوان خارجي، وهو ما يخشاه الناس فعلًا. لكنه يستطيع وضع الأوامر. نطاق الضرر محدود لا معدوم، وسيكون من غير الأمانة وصفه بالمعدوم.
تبقى على المستخدم التزامات. تدوير المفاتيح، وعدم إعادة استخدام المفاتيح عبر الخدمات، ومراقبة ما الذي يملك وصولًا آخر إلى الحساب نفسه، كلها تبقى مسؤوليته. معماريتنا تحدّ من الضرر؛ لكنها لا تجعل المفتاح غير ضار.
ما الذي سأقوله لفريق آخر
- اطلب أضيق نطاق، ثم تحقق أنك حصلت عليه. طلب الأقل ليس مثل تلقّي الأقل.
- فضّل الضمانات المفروضة خارج شفرتك البرمجية، خاصة تلك التي يستطيع المستخدم التحقق منها دون أن يثق بك.
- اجعل الرفض خاليًا من الآثار الجانبية. إذا كان تدفقك يكتب في حساب طرف ثالث، فكل ما يكتب يأتي بعد قرار القبول.
- رمّز القاعدة حيث ينظر المستهلكون بالفعل. القاعدة المعبَّر عنها في نوع مشترك لا تحتاج إلى أن يتذكرها كل مُستدعٍ.
النقطة الأكبر هي أن «لن نفعل X» و«لا نستطيع فعل X» تُقرآن بشكل متشابه في صفحة هبوط، وهما مختلفتان تمامًا في أثناء حادثة. وكلما استطعت نقل وعد من الفئة الأولى إلى الثانية، كانت التكلفة عادةً صغيرة، وظهر المردود بالضبط حين يسير كل شيء آخر نحو الأسوأ.