বাজার অস্থির হওয়ার আগে কোনো আগাম সংকেত বা মিটিংয়ের আমন্ত্রণ পাঠায় না। আকস্মিক সুদের হার হ্রাস, অপ্রত্যাশিত নির্বাচনের ফলাফল বা হঠাৎ ভূ-রাজনৈতিক উত্তেজনা কয়েক সেকেন্ডের মধ্যে সম্পদের দামকে ব্যাপকভাবে পরিবর্তন করে দিতে পারে। ট্রেডাররা দ্রুত তাদের স্ক্রিনের দিকে ছুটে আসেন। কেনা এবং বেচার অর্ডারগুলো স্তূপাকার হতে থাকে। আপনার অবকাঠামোকে কোনো প্রকার জড়তা ছাড়াই সেই ধাক্কা সামলে নিতে হবে। যখন কয়েক মিনিটের মধ্যে ভলিউম দশগুণ বেড়ে যায়, তখন ধীর গতি, অর্ডার ব্যর্থ হওয়া বা সম্পূর্ণ সিস্টেম বন্ধ হয়ে যাওয়া কেবল সামান্য অসুবিধা নয়; এগুলো গ্রাহকের আস্থা নষ্ট করে দেয়।
এই মুহূর্তগুলো কাটিয়ে উঠতে সক্ষম এমন একটি ট্রেডিং প্ল্যাটফর্ম তৈরি করার অর্থ হলো শুরুতেই স্থাপত্যগত (architectural) সিদ্ধান্ত নেওয়া। যদি ডিজাইনটি ভঙ্গুর হয়, তবে কেবল brute-force ক্ষমতা আপনাকে রক্ষা করতে পারবে না। অস্থিরতাকে কেবল একটি সাধারণ ট্রাফিক স্পাইক হিসেবে না দেখে কীভাবে এই সমস্যার সমাধান করা যায়, তা নিচে আলোচনা করা হলো।
এমন ক্লাউড ইনফ্রাস্ট্রাকচার দিয়ে শুরু করুন যা প্রয়োজন অনুযায়ী নমনীয়
অনমনীয় হার্ডওয়্যার আপনার শত্রু। আপনি যদি গড় দৈনিক ভলিউমের জন্য সার্ভার প্রস্তুত করেন, তবে হঠাৎ কোনো বড় পরিবর্তনের সময় আপনি ডুবে যাবেন। আবার যদি চরম পরিস্থিতির কথা মাথায় রেখে সব প্রস্তুত করেন, তবে বছরের বাকি সময় অলস বসে থাকা মেশিনের জন্য প্রচুর অর্থ অপচয় হবে।
ক্লাউড ইনফ্রাস্ট্রাকচার auto-scaling-এর মাধ্যমে এই সমস্যার সমাধান করে। চাহিদার সাথে সাথে কম্পিউটিং ক্ষমতা স্বয়ংক্রিয়ভাবে বৃদ্ধি পাওয়া উচিত। একটি শান্ত মঙ্গলবার সকালে আপনি খুব সামান্য রিসোর্স ব্যবহার করবেন। কিন্তু যখন কোনো জব রিপোর্ট প্রকাশিত হয় এবং অর্ডারের প্রবাহ তিনগুণ বেড়ে যায়, তখন লোড ভাগ করে নেওয়ার জন্য নতুন instances চালু হবে। মূল বিষয়টি হলো এমন scaling policies কনফিগার করা যা যথেষ্ট দ্রুত প্রতিক্রিয়া জানায়। অনুমানের ওপর নির্ভর না করে request queue depth, CPU utilization এবং network throughput-এর ওপর ভিত্তি করে আপনার থ্রেশহোল্ড সেট করুন। এছাড়া, আপনার আর্কিটেকচার বিভিন্ন regions-এ ছড়িয়ে দিন। বিভিন্ন টাইম জোনের ট্রেডারদের প্রয়োজন না হলে একই compute pool-এর জন্য লড়াই করতে হবে না। Regional redundancy ল্যাটেন্সি কম রাখে এবং কোনো একটি ডেটা সেন্টার সমস্যায় পড়লে বিকল্প ব্যবস্থা হিসেবে কাজ করে।
প্ল্যাটফর্মটিকে Microservices-এ বিভক্ত করুন
সবকিছু একটি বিশাল codebase-এ চালানো মানে হলো সব ডিম একটি ঝুড়িতে নিয়ে দৌড়ানো। একটি monolithic অ্যাপ্লিকেশনে, আপনার portfolio charting টুলের একটি memory leak আপনার order execution ইঞ্জিনকে ক্র্যাশ করাতে পারে। অস্থির বাজারের ক্ষেত্রে, এই ধরনের coupling বা আন্তঃনির্ভরতা অগ্রহণযোগ্য।
প্ল্যাটফর্মটিকে স্বাধীন পরিষেবা বা microservices-এ বিভক্ত করুন। Market data ingestion থেকে user authentication-কে আলাদা রাখুন। Portfolio management এবং payment processing থেকে order execution-কে বিচ্ছিন্ন করুন। যখন একটি component অতিরিক্ত চাপের মুখে পড়ে, তখন আপনি সিস্টেমের বাকি অংশকে বিরক্ত না করেই এটিকে scale করতে পারেন। উদাহরণস্বরূপ, যদি কোনো meme stock ভাইরাল হয় এবং সবাই দাম দেখতে চায়, তবে আপনার market data service scale out হতে পারে, যেখানে আপনার order execution clusterটি প্রকৃত ট্রেডের জন্য সংরক্ষিত থাকবে। টিমগুলো matching engine স্পর্শ না করেই মঙ্গলবার বিকেলে payment gateway-তে ফিক্স বা সমাধান প্রয়োগ করতে পারে।
এই বিভাজন বজায় রাখতে শৃঙ্খলার প্রয়োজন। আপনার প্রয়োজন স্পষ্ট API, শক্তিশালী inter-service communication patterns এবং graceful degradation নিয়ম। যদি স্পাইকের সময় portfolio charts ধীর হয়ে যায়, তবে তা বিরক্তিকর। কিন্তু যদি order book ফ্রিজ হয়ে যায়, তবে তা বিপর্যয়কর। শুরু থেকেই failure isolation-এর কথা মাথায় রেখে ডিজাইন করুন।
নির্ভুলতা বজায় রেখে দ্রুতগতির জন্য তৈরি করুন
ইলেকট্রনিক ট্রেডিংয়ে low latency কোনো বিলাসিতা নয়। যদি আপনার validation এবং risk checkগুলোতে অপ্রয়োজনীয় বিলম্ব ঘটে, তবে ট্রেডাররা তাদের কাঙ্ক্ষিত লেভেল মিস করবেন। প্ল্যাটফর্মটি প্রযুক্তিগতভাবে অনলাইন থাকা সত্ত্বেও ব্যবহারকারীর কাছে এটি ত্রুটিপূর্ণ মনে হবে।
অর্ডারগুলো ন্যূনতম বিলম্বের সাথে validation এবং risk assessment-এর মধ্য দিয়ে প্রবাহিত হতে হবে। এর মানে এই নয় যে আপনি কাজের মান কমিয়ে দেবেন। এর মানে হলো এমন চেক ডিজাইন করা যা computationally দক্ষ। প্রতিটি tick-এর জন্য relational database কুয়েরি করার পরিবর্তে credit limits এবং position check-এর জন্য in-memory data grids ব্যবহার করুন। অর্ডার matching ইঞ্জিনে পৌঁছানোর আগেই গেটওয়েতে অর্ডারের syntax validate করুন। যেখানে সম্ভব anti-fraud এবং compliance রুলগুলো সমান্তরালভাবে (in parallel) চালান।
নির্ভুলতা হলো এই সমীকরণের একটি আপোষহীন অংশ। গতির জন্য নির্ভুলতার সাথে আপস করা যাবে না। একটি দ্রুত কিন্তু ভুল অর্ডার পূরণ হওয়া একটি ধীরগতির অর্ডারের চেয়েও খারাপ। আপনার সিস্টেমকে অবশ্যই কঠোরভাবে...