Push vs Pull: Економіка масштабу [ukr]
Більшість систем починаються з push, бо це здається природним — сервер знає, коли щось змінилось, і одразу повідомляє клієнтів. Але у масштабі push містить прихований множник витрат: підключені користувачі × відкриті об'єкти × частота оновлень. Кожна мілісекунда свіжості даних оплачується кожним підключеним користувачем — навіть тим, хто не дивиться на екран.
Доповідь побудована на реальному production-кейсі у DraftKings. Розглянемо, як модель доставки даних визначає форму кривої витрат, а не лише профіль затримок. Пройдемо:
- оригінальну push-систему та те, як вона накопичувала складність роками
- точки болю при масштабуванні, які зробили її нежиттєздатною під піковим навантаженням
- процес оцінки альтернатив, який привів до short polling
- стратегію міграції без downtime у чотири фази
Результати виявились контрінтуїтивними: pull-архітектура з коротким polling-ом показала кращу актуальність даних під піковим навантаженням при суттєвому зниженні споживання CPU та витрат на інфраструктуру. Доповідь завершується практичним фреймворком: коли обирати push, коли pull, і яке питання поставити першим.
- Архітектор програмного забезпечення з 10+ роками в архітектурі та 20+ роками в IT загалом, спеціалізація — high-load розподілені системи
- Наразі в DraftKings Inc., відповідає за архітектуру core-платформи у сфері ставок на спорт
- Досвід охоплює фінансові та ігрові технології; проектування систем, stream processing та масштабованість
- Випускник НТУУ «Київський політехнічний інститут»