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

Коли дані розкидані по десятках сервісів — класичні підходи не працюють. Розкажемо, як ми побудували агреговану read-модель для 30M+ документів, витримали 1500 write RPS і чому Elasticsearch став ключовим компонентом каталогу.

Масштабування системи з 66 мільйонів до понад 25 мільярдів записів - завдання не для людей зі слабкими нервами, особливо якщо мова йде про фінансову систему, де точність не підлягає обговоренню, а затримка даних не є прийнятним варіантом. У цій доповіді Дмитро розповість про реальний шлях масштабування такої системи, залишаючись при цьому здоровим глуздом і зберігаючи правильні цифри. Ви дізнаєтесь, як жонглювати надвисокою точністю та низькою затримкою, оптимізувати логіку вашого додатку та обійти звичайні пастки, які виникають при масштабуванні баз даних. Ця доповідь не про глибоке занурення у внутрішні деталі - вона про обмін прагматичними стратегіями, які допоможуть вам масштабувати, не потонувши у складнощах. Ідеально підходить для інженерів та системних архітекторів, які прагнуть вирішувати серйозні проблеми масштабування з ясністю та впевненістю.