சந்தைகள் பெரும் மாற்றங்களுக்கு முன்னதாகத் தகவல்களைத் தருவதில்லை. எதிர்பாராத வட்டி விகிதக் குறைப்பு, எதிர்பாராத தேர்தல் முடிவு அல்லது திடீர் புவிசார் அரசியல் மோதல்கள் ஆகியவை சொத்து விலைகளைச் சில நொடிகளில் மாற்றக்கூடும். வர்த்தகர்கள் தங்கள் திரைகளை நோக்கி விரைந்து வருவார்கள். வாங்குதல் மற்றும் விற்பனை ஆர்டர்கள் குவிந்து கொண்டே இருக்கும். உங்கள் உள்கட்டமைப்பு (infrastructure) எந்தத் தடங்கலும் இன்றி அந்த அதிர்ச்சியைத் தாங்கிக்கொள்ள வேண்டும். சில நிமிடங்களில் வர்த்தக அளவு பத்து மடங்கு அதிகரிக்கும் போது, மெதுவான வேகம், தோல்வியடைந்த ஆர்டர்கள் மற்றும் முழுமையான முடக்கம் ஆகியவை சிறிய இடையூறுகள் அல்ல. அவை நம்பிக்கையைச் சிதைப்பவை.
இத்தகைய தருணங்களைத் தாங்கி நிற்கும் ஒரு வர்த்தகத் தளத்தை (trading platform) உருவாக்குவது என்பது ஆரம்பத்திலேயே சரியான கட்டமைப்புத் தேர்வுகளைச் செய்வதாகும். வடிவமைப்பு பலவீனமாக இருந்தால், வெறும் கணினித் திறன் (brute-force horsepower) மட்டுமே உங்களைக் காப்பாற்றாது. ஏற்ற இறக்கங்களை (volatility) வெறும் போக்குவரத்து அதிகரிப்பாக (traffic spike) மட்டும் பார்க்காமல், இந்தப் பிரச்சினையை எவ்வாறு அணுகுவது என்பது இங்கே கொடுக்கப்பட்டுள்ளது.
சுவாசிக்கக்கூடிய கிளவுட் உள்கட்டமைப்பிலிருந்து (Cloud Infrastructure) தொடங்குங்கள்
கடினமான வன்பொருள் (Rigid hardware) உங்கள் எதிரி. நீங்கள் சராசரி தினசரி வர்த்தக அளவிற்காக மட்டுமே சர்வர்களைத் தயார் செய்தால், வர்த்தகம் அதிகரிக்கும் போது நீங்கள் மூழ்கிவிடுவீர்கள். அதே சமயம், மிக மோசமான சூழ்நிலையை முன்னரே கருதித் தயார் செய்தால், மீதமுள்ள காலங்களில் பயன்படுத்தப்படாத இயந்திரங்களுக்காக நீங்கள் அதிகப் பணத்தைச் செலவிடுவீர்கள்.
கிளவுட் உள்கட்டமைப்பு இதை 'auto-scaling' மூலம் தீர்க்கிறது. தேவைக்கேற்ப கணினித் திறன் தானாகவே வளர வேண்டும். ஒரு அமைதியான செவ்வாய்க்கிழமை காலை, நீங்கள் குறைந்த அளவிலேயே இயங்குவீர்கள். ஆனால் வேலைவாய்ப்பு அறிக்கை வெளியாகி ஆர்டர்களின் எண்ணிக்கை மூன்று மடங்காகும் போது, சுமையைப் பகிர்ந்து கொள்ள புதிய இன்ஸ்டன்ஸ்கள் (instances) உருவாகும். விரைவாகச் செயல்படும் 'scaling policies'-களை அமைப்பதே இதன் முக்கியமாகும். யூகத்தின் அடிப்படையில் செயல்படாமல், request queue depth, CPU utilization மற்றும் network throughput ஆகியவற்றின் அடிப்படையில் உங்கள் வரம்புகளை (thresholds) நிர்ணயிக்கவும். மேலும், உங்கள் கட்டமைப்பைப் பல்வேறு பிராந்தியங்களில் (regions) பரப்பவும். வெவ்வேறு கால மண்டலங்களில் (time zones) உள்ள வர்த்தகர்கள் ஒரே கணினித் தொகுப்பிற்காகப் போராட வேண்டிய அவசியமில்லை. பிராந்தியத் தொடர்ச்சி (Regional redundancy) தாமதத்தைக் (latency) குறைப்பதோடு, ஒரு தரவு மையம் (data center) சிரமப்படும்போது மாற்று வழியையும் வழங்குகிறது.
தளத்தைப் நுண் சேவைகளாகப் (Microservices) பிரியுங்கள்
அனைத்தையும் ஒரே பெரிய குறியீட்டுத் தொகுப்பில் (codebase) இயக்குவது என்பது எல்லா முட்டைகளையும் ஒரே கூடையில் வைத்துக்கொண்டு ஓடுவது போன்றது. ஒரு monolithic application-இல், உங்கள் போர்ட்ஃபோலியோ வரைபடக் கருவியில் (portfolio charting tool) ஏற்படும் நினைவகக் கசிவு (memory leak), உங்கள் ஆர்டர் நிறைவேற்றும் இயந்திரத்தை (order execution engine) முடக்கிவிடும். ஏற்ற இறக்கமான சந்தைகளில், இத்தகைய பிணைப்பு (coupling) ஏற்றுக்கொள்ள முடியாதது.
தளத்தை தனித்தனிச் சேவைகளாகப் பிரியுங்கள். பயனர் அங்கீகாரத்தை (user authentication) சந்தைத் தரவு உள்ளீட்டிலிருந்து (market data ingestion) தனித்தனியாகக் கையாளவும். ஆர்டர் நிறைவேற்றுதலை (order execution), போர்ட்ஃபோலியோ மேலாண்மை மற்றும் கட்டணச் செயலாக்கத்திலிருந்து (payment processing) தனிமைப்படுத்தவும். ஒரு கூறு (component) அதிக சுமையைச் சந்திக்கும் போது, மற்ற அமைப்பைப் பாதிக்காமல் அதை மட்டும் நீங்கள் விரிவாக்க முடியும். உதாரணமாக, ஒரு meme stock பிரபலமடைந்து அனைவரும் விலையைச் சரிபார்க்க விரும்பினால், உங்கள் சந்தைத் தரவுச் சேவை (market data service) விரிவடையலாம், அதே நேரத்தில் உங்கள் ஆர்டர் நிறைவேற்றும் தொகுப்பு (order execution cluster) உண்மையான வர்த்தகங்களுக்காக மட்டுமே ஒதுக்கப்பட்டிருக்கும். குழுக்கள் matching engine-ஐத் தொடாமல், ஒரு செவ்வாய்க்கிழமை மதியம் கட்டண நுழைவாயிலில் (payment gateway) திருத்தங்களைச் செயல்படுத்த முடியும்.
இந்தத் தனிமைப்படுத்தலுக்கு ஒழுக்கம் தேவை. தெளிவான APIs, வலுவான சேவைகளுக்கு இடையிலான தகவல் தொடர்பு முறைகள் (inter-service communication patterns) மற்றும் graceful degradation விதிகள் உங்களுக்குத் தேவை. ஒரு உச்சக்கட்டத்தின் போது போர்ட்ஃபோலியோ வரைபடங்கள் தாமதமானால், அது எரிச்சலூட்டும். ஆனால் ஆர்டர் புத்தகம் (order book) முடங்கினால், அது பேரழிவாகும். ஆரம்பத்திலிருந்தே தோல்வித் தனிமைப்படுத்தலுக்காக (failure isolation) வடிவமைக்கவும்.
துல்லியத்தை விட்டுக்கொடுக்காத வேகத்திற்காக உருவாக்குங்கள்
மின்னணு வர்த்தகத்தில் (electronic trading) குறைந்த தாமதம் (low latency) என்பது ஒரு ஆடம்பரமல்ல. உங்கள் சரிபார்ப்பு மற்றும் இடர் மதிப்பீடுகள் (validation and risk checks) தேவையற்ற தாமதத்தை ஏற்படுத்தினால், வர்த்தகர்கள் தங்களின் இலக்குகளைத் தவறவிடுவார்கள். தொழில்நுட்ப ரீதியாகத் தளம் இயங்கிக் கொண்டிருந்தாலும், அது பழுதானது போன்ற உணர்வைத் தரும்.
ஆர்டர்கள் குறைந்தபட்சத் தாமதத்துடன் சரிபார்ப்பு மற்றும் இடர் மதிப்பீடுகளின் வழியாகச் செல்ல வேண்டும். அதற்கு குறுக்கு வழிகளைப் பயன்படுத்துவது என்று அர்த்தமல்ல. கணக்கீட்டு ரீதியாகத் திறமையான சரிபார்ப்புகளை வடிவமைப்பதே அதன் பொருள். ஒவ்வொரு முறையும் relational database-ஐத் தேடுவதற்குப் பதிலாக, கடன் வரம்புகள் மற்றும் நிலையைச் சரிபார்க்க in-memory data grids-ஐப் பயன்படுத்தவும். ஆர்டர் matching engine-ஐச் சென்றடைவதற்கு முன்பே, நுழைவாயிலிலேயே (gateway) ஆர்டர் முறையைச் (order syntax) சரிபார்க்கவும். முடிந்தவரை மோசடித் தடுப்பு மற்றும் இணக்க விதிகளை (anti-fraud and compliance rules) இணையாக (parallel) இயக்கவும்.
துல்லியம் என்பது சமன்பாட்டின் விட்டுக்கொடுக்க முடியாத பகுதி. வேகம் துல்லியத்தைப் பாதிக்கக்கூடாது. மெதுவான ஒரு வர்த்தகத்தை விட, வேகமான ஆனால் தவறான ஒரு வர்த்தகம் மோசமானது. உங்கள் அமைப்பு கடுமையான