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.

In high-load systems, infrastructure costs often grow not because of the load itself, but because of inefficient architectural decisions: overprovisioning, excessive use of managed services, unnecessary data movement, incorrect SLA decisions, and the lack of a transparent cost model. At the conference, we will discuss how to approach cost optimization as a full-fledged architectural practice, rather than a one-time resource reduction exercise. We will also cover workload profile analysis, identifying real bottlenecks, building unit economics for infrastructure, traffic optimization, caching, CDN, observability, and controlled service degradation. Separately, we will look at the trade-off between performance, reliability, and cost: where maximum fault tolerance is truly required, where an eventually consistent approach is sufficient, and where managed solutions should be replaced with a simpler self-hosted architecture.

Ten years ago, we pulled libraries and frameworks into our projects not because we wanted to — but because we had to. It was the only way to survive the “browser wars” era and avoid drowning in spaghetti code. Frameworks became our спасіння, and we got used to them. Since then, the web has evolved — but our habits haven’t. HTML, CSS, and JavaScript have made huge leaps forward, yet we still automatically pull in megabytes of abstractions just to render a simple product list — and proudly call it a “modern stack.” It’s time to ask ourselves some uncomfortable questions: • What problems do frameworks actually solve today — beyond our fear of being left alone with plain JavaScript? • Where is the line where “developer comfort” turns into unnecessary weight for the product? • Have frameworks become just a convenient shield — hiding our reluctance to truly understand the platform? I’m not saying we should delete React tomorrow (although…). But I do want to explore this: do frameworks still solve real technical problems — or are we just building another “Hello World” in React because we’ve forgotten how to do it any other way?

Most engineers eventually face the need to perform load testing: validating how a service scales, testing a new database, or running performance benchmarks for a new technology. At that point the obvious question arises — which tool should you use? Existing solutions work well for HTTP load testing, but they often become limiting when you need to test other protocols, model complex workload patterns (open vs closed systems, skewed distributions, hot partitions), or run distributed load testing in a cluster. In this talk, I will introduce NBomber — a load testing framework I created to address these challenges. We will cover: - why there was a need to build a new tool despite the existence of Gatling, Locust, and k6 - using .NET and F# to build latency-sensitive systems - the architecture of NBomber - how NBomber Cluster works - several practical use cases including database benchmarks, anomaly detection, Kubernetes integration, benchmark comparison, and performance trend analysis.

Let’s be honest: in most teams, performance optimization only becomes a priority when something is already on fire. And even then, it’s usually handled by one or two people. Not because others don’t care — but because real optimization requires a lot of time, context, and expertise. At Temabit, we decided to experiment with a different approach: delegating part of the optimization work to agents. In this talk, I’ll share what came out of it: how we learned to frame optimization tasks so agents can produce useful results, how we validate their suggestions, and why optimization turned out to be much harder to delegate than writing code — but potentially far more valuable. Real cases, honest lessons, no hype. And one key question: how realistic is it to trust agents with the performance of your product?

This talk is dedicated to the practical experience of transitioning from the classic Istio architecture with sidecar containers to a new model - Istio Ambient Mesh. We will tell how scaling a microservice infrastructure on Kubernetes led to increased resource costs, complicated CI/CD, and delays in launching services. The search for solutions led us to implement Ambient Mesh, an architecture without sidecar containers that greatly simplifies mesh integration and reduces infrastructure costs. The presentation will detail the technical aspects of the migration: how we prepared for the transition, what challenges we faced during the implementation process, and how we managed to overcome them in cooperation with the Istio community. We will share the results, analytics, real before/after metrics, and give practical advice to teams planning to implement Ambient Mesh in production.

Let's talk about our history. How we started the project with a small vector database of less than 2 million records. Later, we received a request for +100 million records, then another +100... And so gradually we reached almost 1 billion. Standard tools were quickly running out of steam - we were running into performance, index size, and very limited resources. After a long series of trials and errors, we built our own low-cost cluster, which today stably processes thousands of queries to more than 1B vectors.

In this talk, I'll discuss how Reacts' often overlooked concurrent features like startTransition, useDeterredValue and Suspense can transform an application's performance and responsiveness. Participants will learn practical techniques to prioritise critical updates, gracefully handle loading states, and create fluid user experiences even with complex data interactions.

In this talk, we will explore the micro frontend architecture based on the real example of the big product, uncovering how dozens of teams coexist, work, and deploy features independently every day. Moreover, I will talk about the bottlenecks of React hydration, how it affects users, and how to apply the progressive hydration pattern to improve web performance.

Software performance engineering (SPE) aims to build predictable performance into systems by specifying and analyzing quantitative behavior from the beginning of a system to its deployment and evolution. We should also apply this thinking to the data portions of our applications and systems. Performing data operations with Entity Framework Core 8 can seem simple, but there is a hidden part of this framework that can allow developers to unlock the performance users expect. We will lean into this, explore those EF Core features, and leave the talk as better developers.