مارکیٹیں ہلچل مچانے سے پہلے کوئی اطلاع یا دعوت نامہ نہیں بھیجتیں۔ شرح سود میں اچانک کمی، غیر متوقع انتخابی نتائج، یا اچانک جغرافیائی سیاسی کشیدگی اثاثوں کی قیمتوں کو سیکنڈوں میں تیزی سے اوپر نیچے کر سکتی ہے۔ ٹریڈرز اپنی اسکرینوں کی طرف دوڑتے ہیں۔ خرید و فروخت کے آرڈرز کا ڈھیر لگ جاتا ہے۔ آپ کے انفراسٹرکچر کو بغیر کسی رکاوٹ کے اس جھٹکے کو برداشت کرنا چاہیے۔ جب منٹوں میں حجم دس گنا بڑھ جائے، تو سست رفتار، ناکام آرڈرز، اور مکمل طور پر سسٹم کا بند ہو جانا محض معمولی پریشانیاں نہیں رہتیں۔ یہ اعتماد کو ختم کرنے والے عوامل ہیں۔
ایک ایسا ٹریڈنگ پلیٹ فارم بنانا جو ان لمحات میں برقرار رہے، اس کا مطلب ہے کہ شروع میں ہی تعمیراتی (architectural) فیصلے کرنا۔ اگر ڈیزائن کمزور ہو تو محض طاقتور ہارڈ ویئر آپ کو نہیں بچا سکے گا۔ یہاں اس مسئلے سے نمٹنے کا طریقہ بتایا گیا ہے، بغیر اتار چڑھاؤ کو محض ٹریفک میں اضافے کے طور پر دیکھے۔
ایسی کلاؤڈ انفراسٹرکچر سے آغاز کریں جو ضرورت کے مطابق پھیل سکے
سخت (Rigid) ہارڈ ویئر آپ کا دشمن ہے۔ اگر آپ اوسط روزانہ کے حجم کے لیے سرورز فراہم کرتے ہیں، تو اچانک اضافے کے دوران آپ ڈوب جائیں گے۔ اگر آپ انتہائی بدترین صورتحال کے لیے تیاری کرتے ہیں، تو آپ سال کے باقی حصے میں بیکار مشینوں پر پیسہ ضائع کریں گے۔
کلاؤڈ انفراسٹرکچر اسے auto-scaling کے ذریعے حل کرتا ہے۔ جیسے جیسے طلب بڑھے، کمپیوٹنگ پاور خود بخود بڑھنی چاہیے۔ ایک پرسکون منگل کی صبح، آپ کم وسائل پر کام کرتے ہیں۔ جب ملازمتوں کی رپورٹ آتی ہے اور آرڈر کا بہاؤ تین گنا بڑھ جاتا ہے، تو لوڈ بانٹنے کے لیے نئے instances خود بخود شروع ہو جاتے ہیں۔ اصل بات ایسی scaling policies ترتیب دینا ہے جو کافی تیزی سے ردعمل دیں۔ اپنے thresholds کا تعین اندازوں کے بجائے request queue depth، CPU utilization، اور network throughput کی بنیاد پر کریں۔ اس کے علاوہ، اپنے آرکیٹیکچر کو مختلف regions میں تقسیم کریں۔ مختلف time zones کے ٹریڈرز کو، اگر ضرورت نہ ہو تو، ایک ہی compute pool کے لیے مقابلہ نہیں کرنا چاہیے۔ Regional redundancy لیٹنسی کو کم رکھتی ہے اور اگر ایک ڈیٹا سینٹر کو دشواری ہو تو متبادل فراہم کرتی ہے۔
پلیٹ فارم کو Microservices میں تقسیم کریں
سب کچھ ایک ہی بڑے codebase میں چلانا ایسا ہی ہے جیسے تمام انڈے ایک ہی ٹوکری میں ڈال کر دوڑنا۔ ایک monolithic ایپلی کیشن میں، آپ کے پورٹ فولیو چارٹنگ ٹول میں میموری لیک آپ کے order execution engine کو کریش کر سکتا ہے۔ اتار چڑھاؤ والی مارکیٹوں میں، یہ وابستگی ناقابل قبول ہے۔
پلیٹ فارم کو آزاد سروسز میں تقسیم کریں۔ User authentication کو مارکیٹ ڈیٹا کے حصول سے الگ رکھیں۔ Order execution کو پورٹ فولیو مینجمنٹ اور پیمنٹ پروسیسنگ سے الگ کریں۔ جب ایک جزو (component) پر بھاری لوڈ ہو، تو آپ باقی سسٹم کو پریشان کیے بغیر اسے scale کر سکتے ہیں۔ مثال کے طور پر، اگر کوئی meme stock وائرل ہو جائے اور ہر کوئی قیمت چیک کرنا چاہے، تو آپ کی market data service scale ہو سکتی ہے جبکہ آپ کا order execution cluster اصل تجارت کے لیے محفوظ رہ سکتا ہے۔ ٹیمیں matching engine کو چھوئے بغیر منگل کی دوپہر کو payment gateway کے مسائل حل کر سکتی ہیں۔
یہ علیحدگی نظم و ضبط کا تقاضا کرتی ہے۔ آپ کو واضح APIs، مضبوط inter-service communication patterns، اور graceful degradation کے اصولوں کی ضرورت ہے۔ اگر سپائیک کے دوران پورٹ فولیو چارٹس سست ہو جائیں، تو یہ پریشان کن ہے۔ اگر order book منجمد ہو جائے، تو یہ تباہ کن ہے۔ شروع سے ہی failure isolation کے لیے ڈیزائن بنائیں۔
ایسی رفتار کے لیے بنائیں جو درستگی پر سمجھوتہ نہ کرے
الیکٹرانک ٹریڈنگ میں low latency کوئی عیاشی نہیں ہے۔ اگر آپ کی ویلیڈیشن اور رسک چیکس غیر ضروری تاخیر کا باعث بنتی ہیں، تو ٹریڈرز اپنے مطلوبہ لیولز سے محروم رہ جائیں گے۔ پلیٹ فارم ایسا محسوس ہوگا جیسے وہ خراب ہے، چاہے وہ تکنیکی طور پر آن لائن ہی کیوں نہ ہو۔
آرڈرز کو کم سے کم تاخیر کے ساتھ ویلیڈیشن اور رسک اسیسمنٹ سے گزرنا چاہیے۔ اس کا مطلب یہ نہیں کہ کام میں کوتاہی کی جائے۔ اس کا مطلب ہے کہ ایسی چیکنگ ڈیزائن کرنا جو computationally efficient ہو۔ ہر tick پر relational database کو query کرنے کے بجائے credit limits اور position checks کے لیے in-memory data grids کا استعمال کریں۔ آرڈر میچنگ انجن تک پہنچنے سے پہلے ہی gateway پر آرڈر کی syntax کو ویلیڈیٹ کریں۔ جہاں ممکن ہو، anti-fraud اور compliance کے اصولوں کو متوازی (parallel) طور پر چلائیں۔
درستگی اس مساوات کا وہ حصہ ہے جس پر سمجھوتہ نہیں کیا جا سکتا۔ رفتار کو درستگی پر سمجھوتہ نہیں کرنا چاہیے۔ ایک تیز لیکن غلط fill، ایک سست fill سے زیادہ بری ہے۔ آپ کے سسٹم کو سختی سے برقرار رکھنا چاہیے