We built self-aware infrastructure: a system with memory, classifiers, Jev-style decision models, evals and agents that triage what is happening in infrastructure. Most agent deployments are either stateless request handlers or one shared agent that serves everyone. For autonomous triage agents and team experiments we wanted something different. Each team or engineer gets their own always-on agent, a "spot". It remembers their scope, keeps working after they hang up, and is there when they come back. You can ask by voice for "an RCA for each issue from last week", close the session, and find the work finished hours later. This talk covers how we built ttps://triageagent.dev What attendees will take away: 1. Where we started. Oour experiment environment for running agents at scale, built on kagent, agentgateway, ego and substrate. 2. What we got - Triage spots. A live use case for an always-on agent lifecycle: one agent per user, woken by events, with its own memory and quota. 3. An honest list of what we got wrong. The story behind the case: Instead of filing platform tickets and approvals, we introduced sandboxed environment to our teams to reduces the blast radius of untrusted or experimental code on shared clusters at scale. This approach gives a concrete, open example of building a developer-facing portal on top of agent substrate, including the triageagent - winner of India National Awards AI Gamechanger 2026.

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 this presentation, we will explore a practical use case of implementing effective infrastructure autoscaling using HPA, VPA, and Cluster Autoscaler. While working with standard VPA, we encountered several limitations, including a lack of flexibility in configuring calculation intervals and conflicts when running concurrently with HPA. Consequently, we decided to develop our own custom VPA controller. In our new solution, we: - Achieved stable coexistence of VPA and HPA on the same resources. - Implemented a filtering mechanism for transient CPU spikes during the pod startup phase. - Optimized the architecture by consolidating the functionality of three standard components into a single pod. - Leveraged the new In-Place Pod Resize capabilities introduced in Kubernetes 1.33. Key result: Optimized resource consumption and a 20–40% reduction in infrastructure costs.

Have you ever wondered what’s really going on under the hood of distributed systems? Not those “sort of a cluster” setups with 3 nodes, I mean the real deal. The exabyte-scale beasts. In this talk, we’ll peek behind the curtains of modern infrastructure. How do systems that crunch mountains of data actually work? What patterns, principles, and engineering decisions are hiding behind truly scalable architectures? Here’s what we’ll dive into: - What the inner life of a distributed system really looks like - How a distributed app is different from a distributed system - How data storage patterns evolve into modern DBs, queues, and logs - Why “PostgreSQL in the cloud” isn’t really PostgreSQL anymore - Why Northguard might just outshine Kafka - And how new players like NewSQL are changing the game If you’re an architect, tech lead, developer or just curious about why infrastructure scales the way it does - come join! I’ll share insights you might use in your own projects (or at least see them from a new angle). P.S. Yep, there’ll be a bit of magic ✨ and a whole lot of hard truths about the distributed systems powering our world. ?

Design patterns like Event Sourcing and Event Streaming have long become standards for building real-time analytics systems. However, when the system load becomes nonlinear with fast and often unpredictable spikes, it's crucial to respond quickly in order not to lose real-time operating itself. In this talk, I’ll share my experience implementing and using a tool like Temporal.io. We'll explore the evolution of our system for maintaining real-time report generation and discuss how we use Temporal both for short-lived pipelines and long-running background tasks.

What can go wrong if you allow each service to access the database directly? In a startup, this seems like a quick and easy solution, but as the system scales, problems appear that no one could have guessed. In my talk, I'll share Solidgate's experience in transforming its architecture: from the chaos of direct connections to a service-based data access model. I will talk about the transition stages, bottlenecks, and how isolation affected infrastructure support. I will honestly show what worked and what didn't. In short, we will analyze the controversy of this talk.

Taking a system from 66 million to over 25 billion records is not for the faint of heart—especially when the system in question is financial, where precision is non-negotiable and data latency isn’t an option. In this talk, I’ll walk through the real-world journey of scaling such a system while staying sane and keeping the numbers right. You’ll get a look at how to juggle the need for ultra-high accuracy and low-latency performance, streamline your app logic, and sidestep the usual traps that come with database scaling. This session isn’t about deep-diving into internals—it’s about sharing pragmatic strategies that help you scale without drowning in complexity. Ideal for engineers and system architects eager to tackle serious scale challenges with clarity and confidence.</p> <h4>Abstract

We will explore how e-commerce projects prepare for the busiest time of the year, which key aspects to focus on, and what to expect. We’ll share our experience in setting up auto-scaling, load balancing, and discuss the loads that Silpo handles, as well as the solutions that help us navigate this season without failures.

Today, Redis is the de facto standard for caching in application services. It’s incredibly fast and easy to use, giving it a significant advantage in the market. However, as system complexity grows, Redis has several limitations that affect the reliability and availability of your system, especially under high load. In 2025, we are gradually moving away from Redis and rethinking the caching approach as a whole. In this talk, I will share my perspective on the problem and possible solutions. We will explore the challenges associated with Redis and look at alternative solutions for building more resilient and scalable systems.