Більшість систем починаються з push, бо це здається природним — сервер знає, коли щось змінилось, і одразу повідомляє клієнтів. Але у масштабі push містить прихований множник витрат: підключені користувачі × відкриті об'єкти × частота оновлень. Кожна мілісекунда свіжості даних оплачується кожним підключеним користувачем — навіть тим, хто не дивиться на екран. Доповідь побудована на реальному production-кейсі у DraftKings. Розглянемо, як модель доставки даних визначає форму кривої витрат, а не лише профіль затримок. Пройдемо: — оригінальну push-систему та те, як вона накопичувала складність роками — точки болю при масштабуванні, які зробили її нежиттєздатною під піковим навантаженням — процес оцінки альтернатив, який привів до short polling — стратегію міграції без downtime у чотири фази Результати виявились контрінтуїтивними: pull-архітектура з коротким polling-ом показала кращу актуальність даних під піковим навантаженням при суттєвому зниженні споживання CPU та витрат на інфраструктуру. Доповідь завершується практичним фреймворком: коли обирати push, коли pull, і яке питання поставити першим.

В рамках доповіді розкажу про проблеми та нюанси міграції з легасі продуктів. Також на власному прикладі поділюсь як працювали з legacy ми в команді, з якими викликами та проблемами зіткнулись та як виходили з цих ситуацій під час міграції.