വിപണികൾ തകിടം മറിയുന്നതിന് മുമ്പ് മുന്നറിയിപ്പുകൾ നൽകാറില്ല. അപ്രതീക്ഷിതമായ പലിശ നിരക്ക് കുറവ്, അപ്രതീക്ഷിത തിരഞ്ഞെടുപ്പ് ഫലം, അല്ലെങ്കിൽ പെട്ടെന്നുണ്ടാകുന്ന ഭൗമരാഷ്ട്രീയ സംഘർഷങ്ങൾ എന്നിവ സെക്കൻഡുകൾക്കുള്ളിൽ ആസ്തി വിലകളിൽ വലിയ മാറ്റങ്ങൾ വരുത്തിയേക്കാം. വ്യാപാരികൾ തങ്ങളുടെ സ്ക്രീനുകളിലേക്ക് ഓടിയെത്തുന്നു. വാങ്ങൽ, വിൽക്കൽ ഓർഡറുകൾ കുമിഞ്ഞുകൂടുന്നു. നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ തടസ്സമില്ലാതെ ആ ആഘാതം ഉൾക്കൊള്ളാൻ ശേഷിയുള്ളതായിരിക്കണം. മിനിറ്റുകൾക്കുള്ളിൽ വോളിയം പത്തിരട്ടിയായി വർദ്ധിക്കുമ്പോൾ, വേഗത കുറയുന്നതും ഓർഡറുകൾ പരാജയപ്പെടുന്നതും പൂർണ്ണമായ തകരാറുകളും ചെറിയ ബുദ്ധിമുട്ടുകൾ മാത്രമല്ല. അവ വിശ്വാസം തകർക്കുന്ന ഘടകങ്ങളാണ്.
ഇത്തരം സാഹചര്യങ്ങളെ അതിജീവിക്കുന്ന ഒരു ട്രേഡിംഗ് പ്ലാറ്റ്ഫോം നിർമ്മിക്കുക എന്നതിനർത്ഥം തുടക്കത്തിൽ തന്നെ ശരിയായ ആർക്കിടെക്ചറൽ തീരുമാനങ്ങൾ എടുക്കുക എന്നതാണ്. ഡിസൈൻ ദുർബലമാണെങ്കിൽ വെറും കമ്പ്യൂട്ടിംഗ് പവർ കൊണ്ട് മാത്രം കാര്യമില്ല. വോളറ്റിലിറ്റിയെ (volatility) വെറുമൊരു ട്രാഫിക് സ്പൈക്ക് ആയി മാത്രം കാണാതെ ഈ പ്രശ്നത്തെ എങ്ങനെ സമീപിക്കാമെന്ന് നോക്കാം.
ശ്വസിക്കാൻ ശേഷിയുള്ള ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചറിലൂടെ ആരംഭിക്കുക
കർക്കശമായ ഹാർഡ്വെയറുകൾ നിങ്ങളുടെ ശത്രുവാണ്. ശരാശരി ദൈനംദിന വോളിയത്തിന് വേണ്ടി മാത്രം നിങ്ങൾ സെർവറുകൾ സജ്ജീകരിച്ചാൽ, പെട്ടെന്നുണ്ടാകുന്ന വർദ്ധനവിൽ നിങ്ങൾ പരാജയപ്പെടും. എന്നാൽ ഏറ്റവും മോശമായ സാഹചര്യത്തിന് വേണ്ടി മാത്രം തയ്യാറെടുക്കുകയാണെങ്കിൽ, വർഷത്തിന്റെ ബാക്കി സമയങ്ങളിൽ ഉപയോഗശൂന്യമായി കിടക്കുന്ന മെഷീനുകൾക്കായി നിങ്ങൾ വലിയ തുക ചിലവാക്കേണ്ടി വരും.
ഓട്ടോ-സ്കെയിലിംഗിലൂടെ (auto-scaling) ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചർ ഈ പ്രശ്നം പരിഹരിക്കുന്നു. ഡിമാൻഡ് കൂടുന്നതിനനുസരിച്ച് കമ്പ്യൂട്ടിംഗ് പവറും സ്വയമേവ വർദ്ധിക്കണം. ശാന്തമായ ഒരു ചൊവ്വാഴ്ച രാവിലെ, നിങ്ങൾ കുറഞ്ഞ വിഭവങ്ങൾ മാത്രം ഉപയോഗിക്കുന്നു. എന്നാൽ ഒരു ജോബ്സ് റിപ്പോർട്ട് പുറത്തുവരികയും ഓർഡർ ഫ്ലോ മൂന്നിരട്ടിയായി വർദ്ധിക്കുകയും ചെയ്യുമ്പോൾ, ലോഡ് പങ്കിടാനായി പുതിയ ഇൻസ്റ്റൻസുകൾ (instances) സജ്ജമാകുന്നു. വേഗത്തിൽ പ്രതികരിക്കുന്ന സ്കെയിലിംഗ് പോളിസികൾ (scaling policies) കോൺഫിഗർ ചെയ്യുക എന്നതാണ് ഇതിന്റെ പ്രധാന ഘടകം. ഊഹങ്ങൾക്കനുസരിച്ച് ചെയ്യുന്നതിന് പകരം റിക്വസ്റ്റ് ക്യൂ ഡെപ്ത് (request queue depth), CPU യൂട്ടിലൈസേഷൻ (CPU utilization), നെറ്റ്വർക്ക് ത്രൂപുട്ട് (network throughput) എന്നിവയെ അടിസ്ഥാനമാക്കി നിങ്ങളുടെ ത്രെഷോൾഡുകൾ (thresholds) നിശ്ചയിക്കുക. കൂടാതെ, നിങ്ങളുടെ ആർക്കിടെക്ചർ വിവിധ റീജിയനുകളിലായി വിന്യസിക്കുക. വ്യത്യസ്ത ടൈം സോണുകളിലുള്ള വ്യാപാരികൾ ഒരേ കമ്പ്യൂട്ട് പൂളിനായി (compute pool) മത്സരിക്കേണ്ടതില്ല. റീജിയണൽ റിഡൻഡൻസി (Regional redundancy) ലേറ്റൻസി കുറയ്ക്കാനും ഒരു ഡാറ്റാ സെന്ററിന് തകരാർ സംഭവിച്ചാൽ പകരമായി പ്രവർത്തിക്കാനും സഹായിക്കുന്നു.
പ്ലാറ്റ്ഫോമിനെ മൈക്രോസർവീസുകളായി (Microservices) വിഭജിക്കുക
എല്ലാം ഒരു വലിയ കോഡ്ബേസിൽ (codebase) പ്രവർത്തിപ്പിക്കുന്നത് എല്ലാ മുട്ടകളും ഒരു കൊട്ടയിൽ വെച്ച് ഓടുന്നതുപോലെയാണ്. ഒരു മോണോലിത്തിക് ആപ്ലിക്കേഷനിൽ (monolithic application), നിങ്ങളുടെ പോർട്ട്ഫോളിയോ ചാർട്ടിംഗ് ടൂളിലുണ്ടാകുന്ന ഒരു മെമ്മറി ലീക്ക് ഓർഡർ എക്സിക്യൂഷൻ എൻജിനെ തകരാറിലാക്കിയേക്കാം. വോളറ്റൈൽ ആയ വിപണികളിൽ ഇത്തരത്തിലുള്ള ബന്ധം (coupling) അംഗീകരിക്കാനാവില്ല.
പ്ലാറ്റ്ഫോമിനെ സ്വതന്ത്രമായ സേവനങ്ങളായി വിഭജിക്കുക. മാർക്കറ്റ് ഡാറ്റ ഇൻജഷനിൽ (market data ingestion) നിന്ന് ഉപയോക്താക്കളുടെ ഓതന്റിക്കേഷൻ (user authentication) വേർതിരിക്കുക. ഓർഡർ എക്സിക്യൂഷനെ പോർട്ട്ഫോളിയോ മാനേജ്മെന്റിൽ നിന്നും പേയ്മെന്റ് പ്രോസസിംഗിൽ നിന്നും വേർതിരിക്കുക. ഒരു ഘടകത്തിന് വലിയ ലോഡ് നേരിടുമ്പോൾ, സിസ്റ്റത്തിന്റെ മറ്റ് ഭാഗങ്ങളെ ബാധിക്കാതെ തന്നെ അതിനെ സ്കെയിൽ ചെയ്യാൻ നിങ്ങൾക്ക് സാധിക്കും. ഉദാഹരണത്തിന്, ഒരു 'മീം സ്റ്റോക്ക്' (meme stock) വൈറലാകുകയും എല്ലാവരും വില പരിശോധിക്കാൻ ആഗ്രഹിക്കുകയും ചെയ്യുമ്പോൾ, നിങ്ങളുടെ ഓർഡർ എക്സിക്യൂഷൻ ക്ലസ്റ്റർ യഥാർത്ഥ വ്യാപാരങ്ങൾക്കായി മാറ്റിവെക്കുമ്പോൾ തന്നെ മാർക്കറ്റ് ഡാറ്റ സർവീസിനെ സ്കെയിൽ ചെയ്യാൻ സാധിക്കും. ചൊവ്വാഴ്ച ഉച്ചസമയത്ത് മാച്ചിംഗ് എൻജിനെ (matching engine) തൊടാതെ തന്നെ ടീമുകൾക്ക് പേയ്മെന്റ് ഗേറ്റ്വേയിലെ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ കഴിയും.
ഈ വേർതിരിക്കൽ കൃത്യമായ അച്ചടക്കം ആവശ്യപ്പെടുന്നു. നിങ്ങൾക്ക് വ്യക്തമായ APIs, ശക്തമായ ഇന്റർ-സർവീസ് കമ്മ്യൂണിക്കേഷൻ പാറ്റേണുകൾ (inter-service communication patterns), ഗ്രേസ്ഫുൾ ഡിഗ്രഡേഷൻ റൂളുകൾ (graceful degradation rules) എന്നിവ ആവശ്യമാണ്. ഒരു സ്പൈക്കിനിടെ പോർട്ട്ഫോളിയോ ചാർട്ടുകൾ വൈകുന്നത് അലോസരമുണ്ടാക്കാം. എന്നാൽ ഓർഡർ ബുക്ക് ഫ്രീസ് ആകുന്നത് വലിയൊരു ദുരന്തമാണ്. പരാജയങ്ങൾ ഒറ്റപ്പെട്ട രീതിയിൽ നേരിടാൻ (failure isolation) തുടക്കം മുതൽ തന്നെ ഡിസൈൻ ചെയ്യുക.
കൃത്യത നഷ്ടപ്പെടുത്താതെ വേഗതയ്ക്കായി നിർമ്മിക്കുക
ഇലക്ട്രോണിക് ട്രേഡിംഗിൽ ലോ ലേറ്റൻസി (Low latency) എന്നത് ഒരു ആഡംബരമല്ല. നിങ്ങളുടെ വാലിഡേഷനും റിസ്ക് ചെക്കുകളും അനാവശ്യമായ കാലതാമസം വരുത്തുന്നുണ്ടെങ്കിൽ, വ്യാപാരികൾക്ക് അവരുടെ ലക്ഷ്യങ്ങൾ (levels) നഷ്ടപ്പെടും. സാങ്കേതികമായി ഓൺലൈനിൽ ആണെങ്കിൽ പോലും പ്ലാറ്റ്ഫോം തകരാറിലായതായി തോന്നും.
ഓർഡറുകൾ കുറഞ്ഞ കാലതാമസത്തോടെ വാലിഡേഷനിലൂടെയും റിസ്ക് അസസ്മെന്റിലൂടെയും കടന്നുപോകണം. ഇതിനർത്ഥം കാര്യങ്ങൾ എളുപ്പമാക്കുക എന്നല്ല. മറിച്ച്, കമ്പ്യൂട്ടേഷണലി കാര്യക്ഷമമായ ചെക്കുകൾ രൂപകൽപ്പന ചെയ്യുക എന്നതാണ്. ഓരോ ടിിക്കിലും (tick) റിലേഷണൽ ഡാറ്റാബേസ് ക്വറി ചെയ്യുന്നതിന് പകരം ക്രെഡിറ്റ് ലിമിറ്റുകൾക്കും പൊസിഷൻ ചെക്കുകൾക്കുമായി ഇൻ-മെമ്മറി ഡാറ്റാ ഗ്രിഡുകൾ (in-memory data grids) ഉപയോഗിക്കുക. ഓർഡർ മാച്ചിംഗ് എൻജിനിലേക്ക് എത്തുന്നതിന് മുമ്പ് തന്നെ ഗേറ്റ്വേയിൽ വെച്ച് ഓർഡർ സിന്റാക്സ് (order syntax) പരിശോധിക്കുക. സാധ്യമാകുന്ന ഇടങ്ങളിൽ ആന്റി-ഫ്രോഡ് (anti-fraud), കംപ്ലയൻസ് (compliance) നിയമങ്ങൾ സമാന്തരമായി (in parallel) പ്രവർത്തിപ്പിക്കുക.
കൃത്യത എന്നത് വിട്ടുവീഴ്ച ചെയ്യാൻ പാടില്ലാത്ത കാര്യമാണ്. വേഗത കൃത്യതയെ ബാധിക്കരുത്. വേഗതയുള്ളതും എന്നാൽ തെറ്റായതുമായ ഒരു ഫിൽ (fill), സാവധാനത്തിലുള്ള ശരിയായ ഫില്ലിനേക്കാൾ മോശമാണ്. നിങ്ങളുടെ സിസ്റ്റം കർശനമായ