01 / Завдання
Обмеження, що визначило архітектуру.
Наївна модель виконувала серіалізацію, виділення пам’яті й маршрутизацію окремо для кожного з’єднання. За великого розгалуження розсилки вартість зростала і з обсягом подій, і з кількістю підписників, тому типові абстракції фреймворків ставали вузьким місцем.
02 / Архітектура
Рішення, які змінили систему.
- Перенести обробку з’єднань у легкий цикл подій замість окремого важкого шляху виконання для кожного сокета.
- Розповсюджувати за темами спільні незмінні буфери, щоб кожне оновлення ринкових даних кодувалося один раз.
- Використати компактний бінарний протокол, кільцеві буфери й явне керування потоком даних замість повторних виділень пам’яті для JSON.
- Налаштувати мережевий контур і побудувати модель потужності за виміряними витратами пам’яті та CPU на з’єднання.
03 / Результат
Що вдалося створити.
Архітектуру спроєктували для підтримки 500 000 одночасних з’єднань у невеликому кластері зі збереженням операційного резерву. Це задокументована проєктна ціль; незалежний аудит клієнт не публікував.