Most systems start with push because it feels natural — the server knows when something changes, so it notifies clients immediately. But at scale, push embeds a hidden cost multiplier: connected users × open items × update rate. Every millisecond of freshness is paid for by every connected user, even those who aren't watching. This talk is based on a real-world production case study at DraftKings. We’ll explore how the data delivery model shapes the cost curve, rather than just the latency profile. We walk through: — the original push-based system and how it accumulated complexity over the years — the scaling pain points that made it unsustainable under peak load — the evaluation process that led to short polling as the answer — a zero-downtime migration strategy across four phases The results were counter-intuitive: a pull-based architecture with short polling outperformed push on data freshness at peak load, while achieving significant CPU and infrastructure cost reduction. The talk closes with a practical framework for deciding when push wins, when pull wins, and what question to ask first.

I will talk about the problems and nuances of migration from legacy products. Also, using my own experience, I will share how we worked with legacy in our team, what challenges and problems we faced, and how we got out of these situations during migration.