بازارها پیش از آنکه دچار تلاطم شدید شوند، دعوت‌نامه جلسه نمی‌فرستند. یک کاهش نرخ بهره غافلگیرکننده، نتیجه غیرمنتظره انتخابات، یا اصطکاک ژئوپلیتیک ناگهانی می‌تواند قیمت دارایی‌ها را در عرض چند ثانیه دچار نوسان شدید کند. معامله‌گران به سمت صفحه‌های خود هجوم می‌آورند. سفارش‌های خرید و sell روی هم انباشته می‌شوند. زیرساخت شما باید بتواند این شوک را بدون وقفه جذب کند. وقتی حجم‌ها در عرض چند دقیقه ده برابر می‌شود، سرعت پایین، سفارش‌های ناموفق و قطع شدن کامل سرویس، صرفاً مشکلات جزئی نیستند؛ آن‌ها قاتل اعتماد هستند.

ساخت یک پلتفرم معاملاتی که از پس این لحظات بربیاید، مستلزم انتخاب‌های معماری در مراحل اولیه است. اگر طراحی شکننده باشد، قدرت پردازشی خام به تنهایی شما را نجات نخواهد داد. در اینجا نحوه برخورد با این مسئله، بدون اینکه با نوسانات صرفاً به عنوان یک جهش ترافیکی ساده برخورد کنید، آورده شده است.

با زیرساخت ابری که قابلیت تنفس دارد شروع کنید

سخت‌افزار صلب دشمن شماست. اگر سرورها را برای میانگین حجم روزانه تامین کنید، در زمان اوج تقاضا غرق خواهید شد. اگر برای بدترین حالت ممکن تامین کنید، در بقیه سال پول خود را صرف ماشین‌های بیکار خواهید کرد.

زیرساخت ابری این مشکل را با auto-scaling حل می‌کند. قدرت محاسباتی باید همگام با تقاضا به طور خودکار رشد کند. در یک صبح آرام در روز سه‌شنبه، با حداقل منابع کار می‌کنید. وقتی گزارش اشتغال منتشر می‌شود و جریان سفارش‌ها سه برابر می‌شود، instances جدید برای تقسیم بار بالا می‌آیند. نکته کلیدی، پیکربندی سیاست‌های مقیاس‌بندی است که به اندازه کافی سریع واکنش نشان دهند. آستانه‌های خود را به جای حدس و گمان، بر اساس عمق صف درخواست، میزان استفاده از CPU و توان عملیاتی شبکه تنظیم کنید. همچنین، معماری خود را در regions مختلف توزیع کنید. معامله‌گران در مناطق زمانی مختلف نباید اگر مجبور نیستند، برای یک استخر محاسباتی واحد بجنگند. Regional redundancy باعث پایین ماندن latency می‌شود و در صورت بروز مشکل در یکی از مراکز داده، یک جایگزین فراهم می‌کند.

پلتفرم را به Microservices تقسیم کنید

اجرای همه چیز در یک کدبیس عظیم، مانند این است که تمام تخم‌مرغ‌ها را در یک سبد بگذارید و سپس شروع به دویدن کنید. در یک اپلیکیشن monolithic، نشت حافظه (memory leak) در ابزار نمودارگیری سبد سهام شما می‌تواند موتور اجرای سفارش شما را از کار بیندازد. در بازارهای پرنوسان، این coupling غیرقابل قبول است.

پلتفرم را به سرویس‌های مستقل تقسیم کنید. احراز هویت کاربر را جدا از دریافت داده‌های بازار مدیریت کنید. اجرای سفارش را از مدیریت سبد سهام و پردازش پرداخت‌ها ایزوله کنید. وقتی یک جزء با بار سنگین مواجه می‌شود، می‌توانید آن را بدون مختل کردن بقیه سیستم مقیاس‌بندی کنید. به عنوان مثال، اگر یک meme stock وایرال شود و همه بخواهند قیمت را چک کنند، سرویس داده‌های بازار شما می‌تواند مقیاس‌پذیر شود در حالی که کلاستر اجرای سفارش شما برای معاملات واقعی رزرو می‌ماند. تیم‌ها می‌توانند در یک بعدازظهر سه‌شنبه، اصلاحات مربوط به درگاه پرداخت را بدون دست زدن به matching engine اعمال کنند.

این جداسازی نیازمند انضباط است. شما به APIهای شفاف، الگوهای ارتباطی مستحکم بین سرویس‌ها و قوانین graceful degradation نیاز دارید. اگر نمودارهای سبد سهام در زمان اوج تقاضا با تأخیر مواجه شوند، آزاردهنده است. اما اگر order book فریز شود، فاجعه‌بار است. از همان ابتدا برای failure isolation طراحی کنید.

برای سرعتی بسازید که دقت را فدا نکند

low latency در معاملات الکترونیک یک کالای لوکس نیست. اگر اعتبارسنجی و بررسی‌های ریسک شما تأخیر غیرضروری ایجاد کنند، معامله‌گران فرصت‌های خود را از دست خواهند داد. پلتفرم حتی اگر از نظر فنی آنلاین باشد، خراب به نظر می‌رسد.

سفارش‌ها باید با حداقل تأخیر از مراحل اعتبارسنجی و ارزیابی ریسک عبور کنند. این به معنای کوتاهی در کار نیست؛ بلکه به معنای طراحی بررسی‌هایی است که از نظر محاسباتی کارآمد باشند. به جای پرس‌وجو از یک پایگاه داده رابطه‌ای در هر tick، از in-memory data grids برای محدودیت‌های اعتبار و بررسی موقعیت‌ها استفاده کنید. نحو (syntax) سفارش را در gateway قبل از اینکه سفارش به matching engine برسد، اعتبارسنجی کنید. قوانین ضد تقلب و compliance را در صورت امکان به صورت موازی اجرا کنید.

دقت، نیمه غیرقابل مذاکره این معادله است. سرعت نباید دقت را به خطر بیندازد. یک اجرای سریع اما نادرست، بدتر از یک اجرای کند است. سیستم شما باید strict