Push vs Pull: Економіка масштабу – Артем Кузьмик
fwdays
28,5 тис. підписників на YouTube
Додати в плейлист
Завантаження...
Друзі, уже менше, ніж за місяць зустрінемось з вами онлайн на новій події для інженерів, Tech Leads, Software Architects та Engineering Managers, які створюють software в епоху AI!
Відео з конференції Highload fwdays'26, яка пройшла 6 червня 2026 року
Опис доповіді:
Більшість систем починаються з push, бо це здається природним — сервер знає, коли щось змінилось, і одразу повідомляє клієнтів. Але у масштабі push містить прихований множник витрат: підключені користувачі × відкриті об'єкти × частота оновлень. Кожна мілісекунда свіжості даних оплачується кожним підключеним користувачем — навіть тим, хто не дивиться на екран.
Доповідь побудована на реальному production-кейсі у DraftKings. Розглянемо, як модель доставки даних визначає форму кривої витрат, а не лише профіль затримок.
Пройдемо:
- оригінальну push-систему та те, як вона накопичувала складність роками
- точки болю при масштабуванні, які зробили її нежиттєздатною під піковим навантаженням
- процес оцінки альтернатив, який привів до short polling
- стратегію міграції без downtime у чотири фази
Результати виявились контрінтуїтивними: pull-архітектура з коротким polling-ом показала кращу актуальність даних під піковим навантаженням при суттєвому зниженні споживання CPU та витрат на інфраструктуру. Доповідь завершується практичним фреймворком: коли обирати push, коли pull, і яке питання поставити першим.
Сторінка доповіді та презентації:
Більше доповідей та відео за темою конференції:
Понад 16 років Fwdays займається організацією масштабних конференцій та навчанням для розробників таких напрямків: JavaScript, .NET, Python, Data Science, PHP, QA, Highload, Architecture, DevOps, Databases.
Більше інформації про актуальні події:
Відео з конференції Highload fwdays'26, яка пройшла 6 червня 2026 року
Опис доповіді:
Більшість систем починаються з push, бо це здається природним — сервер знає, коли щось змінилось, і одразу повідомляє клієнтів. Але у масштабі push містить прихований множник витрат: підключені користувачі × відкриті об'єкти × частота оновлень. Кожна мілісекунда свіжості даних оплачується кожним підключеним користувачем — навіть тим, хто не дивиться на екран.
Доповідь побудована на реальному production-кейсі у DraftKings. Розглянемо, як модель доставки даних визначає форму кривої витрат, а не лише профіль затримок.
Пройдемо:
- оригінальну push-систему та те, як вона накопичувала складність роками
- точки болю при масштабуванні, які зробили її нежиттєздатною під піковим навантаженням
- процес оцінки альтернатив, який привів до short polling
- стратегію міграції без downtime у чотири фази
Результати виявились контрінтуїтивними: pull-архітектура з коротким polling-ом показала кращу актуальність даних під піковим навантаженням при суттєвому зниженні споживання CPU та витрат на інфраструктуру. Доповідь завершується практичним фреймворком: коли обирати push, коли pull, і яке питання поставити першим.
Сторінка доповіді та презентації:
Більше доповідей та відео за темою конференції:
Понад 16 років Fwdays займається організацією масштабних конференцій та навчанням для розробників таких напрямків: JavaScript, .NET, Python, Data Science, PHP, QA, Highload, Architecture, DevOps, Databases.
Більше інформації про актуальні події:
Ще з цього каналу








Коментарі
+0Коментувати можуть лише зареєстровані користувачі.
Увійти або зареєструватися