Ринки не надсилають запрошення на зустріч перед тим, як у них почнуться конвульсії. Несподіване зниження відсоткової ставки, непередбачуваний результат виборів або раптова геополітична напруженість можуть змусити ціни на активи коливатися за лічені секунди. Трейдери поспішають до своїх екранів. Покупні та продажні ордери накопичуються. Ваша інфраструктура повинна поглинати цей шок без жодних затримок. Коли обсяги зростають у десять разів за лічені хвилини, низька швидкість, помилки при виконанні ордерів та повні збої в роботі — це не дрібні незручності. Це вбивці довіри.
Створення торгової платформи, яка виживає в такі моменти, означає прийняття архітектурних рішень на ранніх етапах. Однієї лише грубої обчислювальної потужності буде недостатньо, якщо дизайн є крихким. Ось як підійти до цієї проблеми, не сприймаючи волатильність як звичайний сплеск трафіку.
Починайте з хмарної інфраструктури, що «дихає»
Жорстка апаратна частина — ваш ворог. Якщо ви виділяєте сервери під середньодобовий обсяг торгів, ви потонете під час сплеску. Якщо ви виділяєте ресурси з розрахунку на найгірший сценарій, ви будете спалювати кошти, тримаючи прості машини решту року.
Хмарна інфраструктура вирішує це за допомогою auto-scaling. Обчислювальна потужність має зростати автоматично разом із попитом. Під час спокійного вівторка ви працюєте з мінімальними витратами. Коли публікується звіт про зайнятість і потік ордерів зростає втричі, запускаються нові екземпляри (instances), щоб розділити навантаження. Ключ до успіху — налаштування політик масштабування, які реагують достатньо швидко. Встановлюйте пороги на основі глибини черги запитів, завантаження CPU та пропускної здатності мережі, а не на основі здогадок. Також розподіляйте свою архітектуру між регіонами. Трейдери в різних часових поясах не повинні боротися за один і той самий пул обчислювальних ресурсів, якщо в цьому немає потреби. Регіональне резервування забезпечує низьку затримку та надає резервний варіант на випадок проблем в одному з дата-центрів.
Розділіть платформу на мікросервіси
Запускати все в одній величезній кодовій базі — це все одно що скласти всі яйця в один кошик, а потім кинутися в біг. У монолітному застосунку витік пам'яті у вашому інструменті побудови графіків портфеля може призвести до збою двигуна виконання ордерів. На волатильних ринках таке пов'язування є неприпустимим.
Розбийте платформу на незалежні сервіси. Обробляйте автентифікацію користувачів окремо від збору ринкових даних. Ізолюйте виконання ордерів від управління портфелем та обробки платежів. Коли один компонент стикається з великим навантаженням, ви можете масштабувати його, не турбуючи решту системи. Наприклад, якщо якась мем-акція стає вірусною і всі хочуть перевірити її ціну, ваш сервіс ринкових даних може масштабуватися, тоді як ваш кластер виконання ордерів залишатиметься зарезервованим для реальних угод. Команди можуть впроваджувати виправлення в платіжний шлюз у вівторок вдень, не чіпаючи matching engine.
Таке розділення потребує дисципліни. Вам потрібні чіткі API, надійні патерни міжсервісної взаємодії та правила поступової деградації (graceful degradation). Якщо графіки портфеля затримуються під час сплеску — це дратує. Якщо книга ордерів зависає — це катастрофа. Проектуйте систему з розрахунком на ізоляцію відмов із самого початку.
Будуйте систему для швидкості, яка не жертвує точністю
Низька затримка (low latency) — це не розкіш в електронній торгівлі. Якщо ваші перевірки валідності та ризиків створюють непотрібну затримку, трейдери пропустять свої цінові рівні. Платформа здаватиметься несправною, навіть якщо вона технічно працює.
Ордери мають проходити через валідацію та оцінку ризиків з мінімальною затримкою. Це не означає ігнорування правил. Це означає проектування перевірок, які є обчислювально ефективними. Використовуйте in-memory data grids для перевірки кредитних лімітів і позицій замість запитів до реляційної бази даних на кожному тіку. Валідуйте синтаксис ордера на рівні шлюзу (gateway) ще до того, як він потрапить у matching engine. Запускайте правила протидії шахрайству та комплаєнсу паралельно, де це можливо.
Точність — це невід'ємна складова рівняння, яка не підлягає обговоренню. Швидкість не повинна шкодити точності. Швидке, але некоректне виконання (fill) гірше за повільне. Ваша система повинна підтримувати сувогу