Hello everyone, and thank you for joining me today. My name is Asif Anwar and I serve as a principal engineer at Walter Stewart. My background, I hold a master's degree in information technology with a specialization in software engineering from Illinois Institute of Technology, Chicago. Over the course of my career, I have gained extensive experience as a software engineer with a focus on building cloud native applications and architecting event driven systems. I'm passionate about designing scalable, resilient solutions that leverage modern cloud technologies, and I look forward to sharing some of these insights with you today. I'm excited to share how we can scale Kubernetes native system using even driven patterns on Azure. You might be wondering why this matters. Our world is moving faster than ever. Customer expects instant response system must scale on demand and downtime is no longer an option. Today we will explore how combining Kubernetes with event driven architecture help us meet these demands. We'll examine our real world case study, how we built a fraud detection system that responds in unjust under two seconds. By the end of this session, you will understand not only the underlying principles, but how to apply them in your own environment. Let's start with the imperative of cloud native and event driven systems. In today's landscape, agility, fault tolerance aren't just nice to have features. They are pretty much non-negotiable. Customer expects a seamless experience, real time responsiveness, and they won't tolerate any outages of service performance. Unfortunately, traditional monolithic architecture make it hard to keep it up. They are rigid. Scaling is course grade and any change or failure risk taking down the whole systems here is what, why Kubernetes steps in to address these pain points. By orchestrating containers, Kubernetes provides a self-healing, automatic scaling and service abstraction. This means we can deploy microservices independently, recover from failure automatically, and scale individual services based on demand. But Kubernetes isn't just a silver bullet. It's primarily an infrastructure and an orchestration layer to achieve the real time agility that modern applications require. We need to embrace event driven patterns. In essence, Kubernetes gives us the foundation, but events makes the foundation come alive. Why focus on event driven architecture? Because it changes how services communicate and scale in an event driven model. Services are loosely coupled. They communicate all synchronously through events. Imagine sending a letter versus making a phone call. You dispatch the letter and move on with your day instead of waiting on the line. This decoupling reduces dependencies and make systems easier to maintain. Even driven architecture also enables scalability, workload expand and contract naturally with the flow of events. If your traffic spikes during a scale or a news event. Your system scales up to meet the demand and then scales back down when the rush is over. Resiliency is another benefit by isolating components. Even driven architecture prevents cascading failures. If one service goes down, the rest of the system keeps it running, and perhaps most importantly, event driven system enable real time interactions. Services response to events. The moment they occur, there is no polling or waiting. In an event driven mindset events are its first class citizens. Instead of building a web of synchronous API calls, we build a network of listeners that respond when something meaningful happens. To implement event driven architecture effectively, we need the right tools. Microsoft Azure provides a comprehensive event driven toolkit. The first piece is event rate. It's a hyperscale event routing service that filters routes and deliver events to subscriber with near real time latency. Then there is a service bus message broker that offers enterprise grade durability and first, first out ordering if an even grid is the nervous system. Service bus is the circulatory system that reliably transport message across the body. The third component is Azure function, which gives us serverless compute to handle events on demand function, scale automatically and charge only for what you consume. Finally, Azure Kubernetes Services, which is a KS. Ties everything together by orchestrating containers and integrating natively with this messaging services. What is remarkable is that these services work seamlessly together. There is no need to stitch together disparate open source com components. Azure provides an integrated ecosystem that speeds sub development and increase reliability. Let's dig a bit deeper into event rate. At its core, even Grid is a highly scalable published subscribed service, which is a pub sub model. It supports massive fanout delivering events to many subscriber with real time latency. Advanced filtering lets you route events based on attributes such as subject type or even custom metadata Built in retype policies and dead lettering handle transient failure automatically. You can think of event data as a central nervous system of your architecture. It routes millions of events per second across your services performance skills to handle millions of events with Subsecond delivery. This makes it ideal for scenarios like IOT Telemetry where thousands of sensors produced data simultaneously, or from micro based architecture where many components need to interact with the same event. Now let's look at service bus. When even grid excels at high volume broadcast service bus focus on reliable message delivery. It provides you with cues and topics with guaranteed persistence, so message aren't lost even if a consumer is offline. Service bus supports sessions to preserve fast first out order, which is essential when your business logic depends on processing events in sequence. Error handling is another key feature. Dead letter queues captures message that can't be delivered, allowing you to analyze and reprocess them later. This is critical in industries where audit trails and message durability are mandatory. For example, consider a very high value financial transaction. If a message is lost or processed out of order, the consequence would be. Service bus is the one which ensures that this never happens. So how do we execute code when these events arrive? This is where Azure functions come in. Functions are serverless units of execution. They react to a variety of triggers. Event grid service bus, rest based HTTP block storage and more. They automatically scale from zero to thousandths of concurrent execution, and you only pay for the resource you consume functions. They really shine at lightweight transformations and orchestration. You can enrich and even filter, transform it, publish it to another service. They are perfect for rusty workloads or glue logic that connects different parts of your architecture. In other words, functions are reactive glue that holds your pipeline together. Now let's look at some of the architectural patterns with event driven architecture. It is not just about tools. It is about using the right patterns. Azure supports several reusable architecture pattern that help manage complexity at scale. This is my favorite. The first is CQRS, which stands for Command Quality Responsibility Segregation. With CQRS, you can separate read and write operations into different models. For example, in an e-commerce site you write such as placing orders, updating an inventory can be fast and eventually consistent. Separating them optimizes performance and scalability. The second pattern is event sourcing. Instead of storing the latest state of an object, you store the sequence of events that led to that state. This approach provides a complete audit trail and allow you to reconstruct any past state. Then there is a pattern saga, basically coordinates complex business transactions across multiple services. Imagine booking a trip or you need to book your flight, you need to book hotel, and you need to rent a car, a saga pattern. Ensure that if any of these step fails, the previous steps are compensated. Let's say for an example, your flight is canceled. Finally balance between choreography and orchestration. In a choreographic system, services reacts to events independently, which promotes autonomy in orchestrated systems. A central controls tells service what to do. Finding the right balance improves coordination without creating a bottleneck to see how these patterns come together, let's examine a real time fraud detection case. Fraudulent transactions cost financial institution billions of dollars every year in direct losses and regulated penalties. Legacy fraud detection systems often took minutes or even hours to identify suspicious activity, far too slow when criminals can exploit weakness in seconds. The goal was ambitious, reduce detection time to under two seconds while achieving 95% accu accuracy. Meeting this goal would not only protect customers, but also transform fraud detection from a reactive process to a proactive one. Here is how we built the system in Azure. First, every transaction generated in our payment services running on Azure Kubernetes services. It's an event. The event goes into an event grid, which immediately routes it to a service bus for reliable ordering. Processing. A dedicated Azure function wakes up and enrich the data with customer history and contextual information. The enriched event is then passed to a machine learning model running in GPU, packed a KS pods. The model evaluates the transaction and returns a fraud score within milliseconds. The final Azure function interprets the score and makes a real time decision, approve the transaction, reject the transaction, or flag the transaction for review, delivering a response in under two seconds. What makes this architecture elegant is how each Azure service plays a distinct role. Event grid dispatches event instantly. Service bus guarantees the order of transactions, functions handle enrichment and orchestration. Azure Kubernetes Services a KS runs the resource intensive machine learning provider models, thus providing the compute together. They form a pipeline that captures every transaction. And reaches it, evaluates it, and responds at all cloud scale. During implementation, we had to plan for the worst. Think of it as a Black Friday when transaction volumes spike down dramatically. Even grid, it can handle millions of events per second, so it doesn't become a bottleneck during those peak hours. Service bus provides automatic retries and dead lettering queues, ensuring that zero messages are lost even if something has gone wrong. Azure function scale instantaneously from zero to thousand of concurrent executions. Meanwhile, the machine learning model run on GPU backed Kubernetes part that scale horizontally to meet demand. What was the result? Through elastic scalability. During peak shopping periods such as Black Friday or any other weekend festival, the system processed millions of simultaneous transactions without any downtime and maintained sub two second response time. This is the power of even driven patterns when it combined with Kubernetes. So what did we achieve? We reduced the average response time from minutes to under two seconds, which means suspicious transactions are flagged almost immediately. We also call cut false positive by 15%, improving the customer experience. The system achieved a hundred percent uptime during peak periods, meaning no outages or degraded performance beyond this metrics. It also gained full observability with correlation ID that trace each event through the system, reduced operational overhead through automation, improved compliance by maintaining comprehensive auditors. All of these benefits translated directly into cost setting, increased customer trust and competitive edge in the market. So what did we learn from building this system? We learned some important lesson that apply to any event driven architecture. First design item, potent flows. Your handler should produce the same result, even if they are processed the same event more than once. This prevent duplicate charges. Ensure consistency using retries. Second plan for schema evolution. Use semantic versioning for your events so consumers can handle both old and new version. Third, always include correlation IDs. They are essential for debugging and tracing events through distributed systems. Finally, implementable strong security pipeline, leveraging managed identities and role based access controls from the. Azure Ensure service communicates securely without hardcore credentials. These elections aren't specific to finance. They apply across any industry that requires scalable, reliable event processing systems, even driven patterns. They unjust limited to fraud detection or even finance industries. In healthcare event driven telemetry monitors patient vitals in real time. Systems can achieve 99% of time and trigger instant alerts when readings deactivate from safe range in retail or synchronous inventory synchronization across multiple stores, reduce lag by 85%, and prevents talk outs during sales in insurance, automated claims. Adjudication combines document processing with fraud detection to speed up reimbursement. These examples demonstrate the versatility of event driven architecture across drivers industries. Now, as we near to end of our journey, let me summarize the key messages. Event driven patterns combined with Kubernetes deliver scalable, resilient, and efficient systems at enterprise scale. Microsoft Azure provides a comprehensive toolkit, event grade service bus, Azure function, and Azure Kubernetes services, which is KKS, that lets you build event driven systems without the glue code. Fraud detection case study shows real world value sub two second latency, zero zone downtime, and improved accuracy and success in healthcare, retail, and insurance prove the broad applicability of these patterns. Importantly, even driven architecture isn't just a theoretical, it is battle tested in production, handling millions of transactions every day. So what's next? If you have a legacy system, consider modernizing them with event driven design. If you're building a new microservices, start with events and choose services like event grid, service bus and serverless compute, like Azure function. The sooner you adopt these patterns, the faster you will reap the benefits of real time. Thank you for your time and attention. I hope you have a clear understanding of how Kubernetes and event driven architecture can transform your systems. I'm happy to answer any question or discuss how these concepts apply to your organization. Thank you so much for your time today.