DRASI: Detect and react to changes in your database. Software Craftsman Solutions Architecture Version 1.0.0, April 2025 Solution Architect @ AVANADE GitKraken Ambassador 

2 2 Reflection: A Path to agnosticism? (1/2) My primary role is acting as a Solutions and Applications Architect, and when necessary, I dive into the code, creating code templates and preparing everything required so that what I request can be implemented effectively. While I prefer delegating these tasks to a trusted leader, I take responsibility when needed to ensure that projects progress as planned. Additionally, I have worn other hats: as an Enterprise Architect, working closely with the CTO to ensure our technological infrastructure aligns with the organization's long-term strategies and objectives. From this perspective, the adoption of technologies like Dapr1 and Keda is crucial (both graduated from the CNCF). These tools provide immediate benefits for managing distributed applications and efficient auto-scaling in Kubernetes. Beyond their operational advantages, they are part of a broader strategy toward a hyper-agnostic infrastructure system, meaning we are building a flexible and adaptable architecture capable of operating in multiple environments without being locked into a single provider. In this context, we are also observing the emergence of new players such as Aspire, which integrates seamlessly with Dapr, microservices, Docker, and other modern technologies. Aspire promises to be a key ally in our transition toward a more agile and efficient infrastructure. Incubating projects like Radius are also of great interest to us. Although they are still under development, they represent the future of interoperability and portability—crucial elements for maintaining the agility and responsiveness of our technological infrastructure. Staying attentive to these advancements allows us to anticipate and prepare for their integration once they are ready for deployment. For organizations that have not yet planned a full migration to the cloud, integrating Kubernetes with technologies like Dapr and Keda represents a strategic first step. This integration not only facilitates a potential transition to the cloud but also enhances our ability to scale and manage applications in on-premises environments. If we ever decide to move our infrastructure to the cloud or switch providers, this strategy will enable us to do so more smoothly and with fewer obstacles. 1I know that many Dapr binding-blocks for Azure technologies, such as Azure Service Bus, have been in alpha phase for several years now. However, the first step was to graduate Dapr to ensure the project's continuity and its ability to integrate effectively into our technological strategies. 

3 3 Reflection: A Path to agnosticism? (2/2) Why does my role require me to stay informed about incubating or sandbox projects? Because you can discover innovations like Drasi, which will enable us to create an event-driven architecture in an agnostic manner, embracing a new philosophy that could be termed "data-driven." Drasi promises to revolutionize our real-time data interaction, enabling faster and more accurate responses to critical business events. Or Backstage, which allows us to create an Internal Developer Platform (IDP). Or COPA, which lets us quickly apply patches to container images without having to rebuild them—a feature especially useful for addressing vulnerabilities in legacy base images or third-party applications that aren't directly maintained. And let's not forget Confidential Containers (here I refer to Confidential Computing). In my role, it's essential to ensure that technological decisions not only meet current needs but also position our organization to tackle future challenges and seize opportunities. The ability to move seamlessly between different environments, whether on-premises or in the cloud, without experiencing the dreaded vendor lock- in, is a competitive advantage we cannot overlook. My personal goal, whether in my role as a Solutions and Applications Architect or as an Enterprise Architect, is to design a resilient and adaptable infrastructure aligned with the organization's strategic vision. I strive to ensure that our resources and focus remain centered on delivering value to the user, avoiding distractions caused by solving problems invisible to them. To conclude, let me offer some advice based on my experience as a professional dedicated to helping companies modernize their applications or develop new ones from scratch. I believe it is critical to make strong architectural decisions that ensure the success of every project. To achieve this, properly documenting Architectural Decision Records (ADRs) is essential, as they provide a clear record of the reasoning behind our choices and how they contribute to successful application development. Additionally, I deeply value maintaining open and honest communication with clients, ensuring everyone is informed and that our partnership is built on trust and transparency. Jose María Flores Zazo, April 2025 

4 4 How is this document organized? • What is it? • What is it used for? • How does it work? • Why use it? • Where can it be applied? • Comparison with other similar technologies • Key concepts • Use Case I • Use Case II • Conclusion https://drasi.io/ 

5 5 What is? (1/3) Drasi is a data processing platform designed to simplify the detection of changes in data systems and trigger automated responses to those changes. It enables the monitoring of records and change streams across various systems, evaluating them for relevance and reacting in real-time. Drasi uses continuous queries that monitor data in real-time. When a change occurs that matches predefined criteria, Drasi triggers contextual actions, making the process efficient and scalable. Drasi's architecture is composed of three fundamental components: • Sources: These connect Drasi to external systems (databases, messaging systems, etc.) and monitor them to detect changes. • Continuous Queries: These queries remain active and are constantly updated as data changes occur. They use the Cypher query language to write complex graph-based queries. • Reactions: These are triggered when Continuous Queries detect relevant changes. Drasi provides standard reactions that send these changes to external systems or execute commands directly within the system. 

6 6 What is? (2/3) D R A S I Data Continuous Queries Reactions External Actions Sources 

7 7 What is? (3/3) Another Change Data Capture (CDC)? If you're experienced with traditional Change Data Capture (CDC) tools and are thinking Drasi is more of the same, let me assure you that's not the case. Drasi goes beyond capturing insert, update, or delete events; its unique approach, based on continuous queries and the Cypher language, enables not only real-time change detection but also the analysis and understanding of complex relationships between data, even when it originates from multiple sources with disparate schemas. Furthermore, its ability to combine relational data, graph data, and external system data, along with configurable reactions that can execute automated actions or integrate in real-time with applications and services, redefines what it means to process changes in data. Drasi isn't just another CDC; it's an evolution that transforms change detection into an intelligent action tool. 

8 8 What is used for? (1/2) Drasi is an innovative platform designed to simplify event management in complex systems by detecting critical changes and executing automated responses in real-time. Through continuous queries, Drasi monitors data from diverse sources such as databases and messaging systems, enabling efficient integration into event-driven architectures. This allows developers to establish predefined criteria to evaluate detected changes and trigger contextual actions tailored to business objectives, thereby optimizing processes in real-time. The platform ensures that responses are timely and relevant, avoiding the need to duplicate data in a Data Lake or perform repetitive queries, making it ideal for IoT applications, security management, and other scenarios where agility and efficiency are essential. Drasi's flexible design enables customization and adaptation to specific environments, facilitating the creation of dynamic and robust solutions that improve business operations. By providing continuous monitoring and rapid reactions to changes, Drasi helps maintain clarity and simplicity in complex systems. Organizations can react quickly to changes and seize real-time opportunities, preserving business agility while optimizing resource use. With its integration and automation capabilities, Drasi represents a significant advancement in managing modern data architectures. 

9 9 What is used for? (2/2) Real-time automation in Drasi ensures timely responses to critical events, enabling organizations to act immediately in important situations. Thanks to its continuous queries, Drasi constantly evaluates changes without needing to duplicate data, maintaining system efficiency. Its flexibility and adaptability allow for customization to specific needs, which is essential for IoT and security environments where efficient management of event-driven architectures is crucial. Additionally, Drasi optimizes resources by maintaining agility and efficiency in data management, ensuring organizations can maximize their performance and responsiveness. Summary: • Real-Time Automation: Timely responses to critical events. • Continuous Queries: Constant evaluation of changes without duplicating data. • Flexibility and Adaptation: Customization according to specific needs. • Ideal for IoT and Security: Improves efficiency in event-driven architectures. • Resource Optimization: Agility and efficiency in data management. • Efficient Integration: Seamless connection with multiple data sources. • Simplicity in Complexity: Simplifies the management of complex systems. 

10 10 Why use it? The platform is designed to address the challenges associated with event-driven architectures, where detecting relevant changes can be overwhelming due to the increasing frequency and complexity of events. Drasi simplifies the automation of intelligent reactions in dynamic systems, providing actionable insights in real-time without the overhead of traditional data processing methods. It uses continuous queries to evaluate incoming changes based on predefined criteria, enabling timely and relevant responses. This is achieved through its three fundamental components: Sources, Continuous Queries, and Reactions. Drasi is ideal for practical applications such as smart building management, where it can monitor room conditions and automatically update control panels. It can also enhance risk management by tracking incidents and alerting key personnel when employees or assets are at risk, optimize delivery systems by triggering actions when customers arrive at pickup zones, and improve security by detecting and responding to potential threats in Kubernetes clusters. Drasi Pros Challenges of traditional systems Reduce operational and engineering burden. Wasted resources when querying unchanged data. Accurate, scalable, and declarative change detection. Complex logic to detect and filter generic events. Standardized framework for reacting to critical changes. Customized solutions to detect and react to events. 

11 11 Where can I use it? (1/5) As a versatile platform, Drasi can be used in various scenarios where real-time change detection and automatic reaction are crucial. Below are some areas and a use case where Drasi can be implemented: • IT Infrastructure Management: Monitoring servers and networks to detect failures or anomalies and automatically activate remediation procedures. • IoT Applications: Integration with smart devices to adjust settings in response to environmental changes or user needs. • Security Systems: Monitoring systems to detect potential threats and trigger alerts or security measures immediately. • Logistics and Transportation: Tracking fleets and optimizing routes based on traffic conditions or delivery requirements. • E-commerce: • Inventory Management: Drasi can monitor inventory levels in real time. When it detects that a product is running low, it can automatically trigger a restocking process, always ensuring stock availability. • Optimization of Offers and Promotions: By detecting trends or changes in customer purchasing behavior, Drasi can automatically adjust offers and promotions to maximize sales and enhance the customer experience. 

12 12 • Order Tracking: Drasi can manage the flow of purchase orders, ensuring that each stage of the process is completed smoothly and notifying the responsible teams if delays or errors are detected. • Personalization of Customer Experience: By analyzing users' browsing and purchase history, Drasi can customize product recommendations and content in real-time, enhancing customer satisfaction and boosting conversions. • Healthcare & Hospital Resource Management: Drasi can assist in optimizing the allocation of hospital resources, such as beds and staff, based on current demand and changes in care needs, improving operational efficiency and patient care. Author's Note If you're thinking about the typical SAGA pattern, let me explain it later. You'll be surprised by the new approach. Author's Note If you're thinking that a WebSocket model fits perfectly with all this about Drasi, you're absolutely right. I believe we’ll be able to make great use of this protocol, especially with Azure SignalR. Where can I use it? (2/5) 

13 13 Comparison between Saga and Drasi for Order Tracking: Saga • Transaction Decomposition: In a system using the Saga pattern, each stage of the purchase order process is represented as an individual transaction. If a stage fails, compensating actions are executed to undo the changes made. • Implementation Complexity: Implementing a Saga pattern requires clearly defining each step and its corresponding compensating actions, which can be complex and require a significant amount of code. • Error Handling: The compensating logic must be carefully designed to ensure that errors are properly managed, which can be a challenging task. Drasi • Reaction Automation: Drasi simplifies the process by automatically detecting changes in the purchase order flow and triggering contextual reactions without the need to decompose transactions into individual stages. • Reduced Complexity: With Drasi, the need to implement compensating actions is minimized, as automated reactions can handle errors in real-time and adjust the process as needed. • Real-Time Monitoring: Drasi provides continuous monitoring, enabling immediate detection and reaction to delays or errors, ensuring the process completes smoothly. Where can I use it? (3/5) Author's Note Drasi does not eliminate the Saga pattern but can radically simplify it in many scenarios where distributed transactions are triggered by data changes and require declarative compensatory actions. 

14 14 Advantages of Using Drasi to Simplify Saga-like Workflows • Simplicity: Drasi reduces implementation complexity by automating the detection and reaction to data changes, minimizing the need to write custom orchestration or choreographic logic for many use cases. • Agility: Its reactive model allows rapid response to data changes and error conditions, reducing time to market and easing iteration. • Scalability: While not designed for extreme throughput scenarios, Drasi can scale effectively for many typical workloads, such as high-volume order management systems, without the overhead of a full event bus. Use case: Event Management in Conference Centers Imagine a system implemented in a conference center that uses Drasi to manage ongoing events. Drasi can monitor room booking records and detect changes in the expected number of attendees, automatically triggering adjustments to the event logistics. If the number of attendees exceeds a predefined threshold, Drasi can send alerts to the catering team to increase the supply of food and beverages, the cleaning team to ensure the facilities are prepared, and the security personnel to adjust their monitoring arrangements. This use of Drasi simplifies dynamic event management, ensuring that all involved teams are informed and able to respond promptly to changes in the event's needs. Where can I use it? (4/5) 

15 15 Sources Room Booking Records (Database) Relations External Actions Ongoing Consultations Registration of the Number of Attendees (Database) Attendee threshold exceeded? Send Alert To the catering team Send Alert To the cleaning team Send Alert To the security team Where can I use it? (5/5) 

16 16 Comparison with other similar technologies (1/6) Debezium Debezium is a data change capture (CDC) platform that enables real-time database monitoring. It integrates with Apache Kafka to stream changes and is compatible with multiple database management systems such as PostgreSQL, MySQL, MongoDB, among others Apache Kafka Although Kafka is primarily an event streaming platform that can be used in combination with CDC tools like Debezium to process and react to database changes. Kafka Streams enables real-time data processing. AWS Lambda y DynamoDB Streams DynamoDB Streams allows capturing changes in DynamoDB tables, and by combining it with AWS Lambda, functions can be created to react to these changes, providing a serverless solution for detecting data changes. The same approach can be applied with Azure Functions y Azure Cosmos DB. 

17 17 Google Cloud Pub/Sub Like Kafka, Google Cloud Pub/Sub is an asynchronous messaging service that can be used to process events and data changes in real-time. It can be integrated with other Google Cloud tools to create automated responses to changes. However, I believe the BigQuery Storage Write API is a better option for this. Change Data Capture (CDC) in SQL Server SQL Server offers CDC functionalities that allow detecting changes in databases. This can be integrated with other systems to react to these events. Firebase Realtime Database Firebase a real-time database that allows instant change detection and reaction, making it especially useful for mobile and web applications. Comparison with other similar technologies (2/6) 

18 18 As you can see, the only viable comparison is between Drasi and Debezium, tools that address change detection in databases but do not rely on the database itself. They operate differently and are designed for distinct purposes. Below are some key differences between the two: Purpose and Focus • Debezium: Its primary goal is to track changes in databases and integrate them into data streaming systems and other applications. • Drasi: Focuses on detecting changes and reacting to them in real-time. It not only captures changes but also provides integrated tools for reacting to these changes through continuous queries and configurable actions. Underlying Technology • Debezium: Relies on Apache Kafka for message streaming. It requires a Kafka ecosystem to function, which involves maintaining an operational Kafka cluster. • Drasi: Does not depend on Kafka or any specific messaging system. It is designed to integrate data sources, queries, and reactions directly within its own framework. Author's Note I will only compare Debezium with Drasi, as the other technologies are not strictly CDC tools. However, I will include a comparison with Azure Stream Analytics so you can see a technology within the Azure ecosystem that could be somewhat similar to Drasi Comparison with other similar technologies (3/6) 

19 19 Implementation and Configuration • Debezium: Requires setting up connectors for each database you want to monitor. This involves a certain level of complexity in the initial configuration, especially in distributed environments. • Drasi: Provides a more integrated approach to configuring data sources, queries, and reactions within a single environment, which can simplify the implementation of complete solutions. Integration and Flexibility • Debezium: Integrates well with other components in the Kafka ecosystem, making it highly flexible for event- driven architectures and microservices. • Drasi: Designed to offer a more comprehensive solution within its own environment, simplifying the creation of solutions that detect and react to changes without relying heavily on external tools. Use Cases • Debezium: Ideal for scenarios requiring data replication, system synchronization, or feeding data streaming systems with database changes. • Drasi: Best suited for applications needing real-time reactions to data changes, such as alert systems, real-time updates, and interactive applications. Debezium focuses solely on capturing and transmitting data changes; Drasi takes a step further by providing integrated capabilities to react to those changes in real time. Comparison with other similar technologies (4/6) 

20 20 Intentionally, I did not include Azure Stream Analytics because I wanted to address it individually. Drasi and Azure Stream Analytics share several features. Both are designed to process and analyze real-time data from various sources. Similarities • Real-Time Processing: Both are designed to process data in real-time, enabling organizations to make quick decisions based on current events. • Continuous Monitoring: Both solutions provide capabilities for continuously monitoring data streams and detecting important changes or patterns. • Data Integration: They allow the integration of data from multiple sources, such as databases, messaging systems, and IoT devices. • Automated Responses: Both platforms can trigger automatic actions in response to specific events, enhancing operational efficiency. Comparison with other similar technologies (5/6) 

21 21 Differences • Implementation Focus: Drasi may offer a more tailored approach for customization and adaptation to specific environments, while Azure Stream Analytics focuses on a more standardized set of analytical capabilities. • Customization Capabilities: Drasi provides a higher level of customization to define specific criteria and actions, whereas streaming platforms like Azure Stream Analytics offer predefined configurations. • Infrastructure and Tools: Azure Stream Analytics is tied to the Azure cloud and its suite of data processing tools, enabling easy integration—even with custom solutions—while Drasi is designed to integrate directly without relying on external services. Although Drasi and Azure Stream Analytics share the goal of processing and responding to real-time data, Drasi helps eliminate vendor lock-in, further reinforcing one of the objectives of Microsoft's ecosystem, which promotes open-source tools designed for the world of containers. Author's Note I assume they chose the Apache 2.0 license over the MIT license (I used to be a defender of MIT for its permissiveness until this happened, and I realized Apache 2.0 was better) because it offers certain advantages, especially if you want to ensure your project doesn't easily become a paid product. Here are the most relevant points: • Patent Clause: The Apache 2.0 license includes a patent grant clause that explicitly licenses users for any patents covered by the project. If a contributor initiates a patent lawsuit against any part of the project, they lose their patent rights under the license. This can discourage entities from turning the project into a paid product based on patents. • Trademark Protection: While both licenses allow commercial use, Apache 2.0 has clearer provisions on trademark use, which can provide additional protection over how the project is commercialized. • Distribution Requirements: The Apache 2.0 license requires maintaining copyright notices and licenses in copies of the software and including a copy of the license, making it harder for someone to privatize the code without meeting these requirements. Remember the changes in Fluent Assertions, MediatR, or some others that are making that shift despite having the MIT license. Comparison with other similar technologies (6/6) 

22 22 Key Concepts (1/9) Sources "Sources" in Drasi provide connectivity to the systems that Drasi can observe as change sources. They perform three important functions: • Process the change log generated by the source system and send it to continuous queries. • Translate the change data into a consistent property graph data model. • Allow continuous queries to initialize the state of the query result. To create a source, the Drasi CLI is used by providing endpoint addresses and credentials for the source system and defining the source resource in a YAML file. apiVersion: v1 kind: Source name: spec: kind: properties: ... source.yaml drasi apply -f source.yaml Crear drasi list source Listar drasi delete source Borrar 

23 23 Key Concepts (2/9) Continuous Queries Continuous Queries are the most important component of Drasi. They allow you to specify which changes to detect in source systems and what data to distribute when changes are detected. Unlike snapshot queries, Continuous Queries run perpetually, maintaining an accurate and up-to-date query result as changes occur in the source database. They are implemented as graph queries written in the Cypher language (a language that's not new, as those who follow me may know it's used in Neo4j for graphs; in this case, given the advancements, it's best to consult the official documentation), enabling the detection of complex changes and generating detailed notifications about them. Continuing with our use case, “Event Management in Conference Centers,” let's assume: • Event Nodes: Each object represents an event, with a unique identifier eventId, a name, the number of expected attendees, and the event date. • Room Nodes: Each object represents a room, with a unique identifier roomId, a name, and the maximum capacity of the room. • Relationship Hosted_In: Each object represents the relationship between an event and a room, indicating which event takes place in which room through the eventId and roomId identifiers. 

24 24 Key Concepts (3/9) [ { "eventId": "ev001", "name": "Tech Conference 2023", "expectedAttendees": 150, "date": "2023-11-10" }, { "eventId": "ev002", "name": "Annual Gala", "expectedAttendees": 80, "date": "2023-12-05" }, { "eventId": "ev003", "name": "Startup Pitch Night", "expectedAttendees": 120, "date": "2023-12-15" } ] [ { "roomId": "rm101", "name": "Main Hall", "capacity": 200 }, { "roomId": "rm102", "name": "Conference Room A", "capacity": 100 }, { "roomId": "rm103", "name": "Banquet Hall", "capacity": 150 } ] [ { "eventId": "ev001", "roomId": "rm101" }, { "eventId": "ev002", "roomId": "rm103" }, { "eventId": "ev003", "roomId": "rm102" } ] Event Hosted_In Room Author's Note The example is relational to make it easier to understand. 

25 25 Key Concepts (4/9) apiVersion: v1 kind: ContinuousQuery name: catering-alert spec: mode: query sources: subscriptions: - id: event-management nodes: - sourceLabel: Event - sourceLabel: Room relations: - sourceLabel: HOSTED_IN joins: - id: EVENT_TO_ROOM keys: - label: Event property: eventId - label: Room property: roomId query: > MATCH (e:Event)-[:HOSTED_IN]->(r:Room) WHERE e.expectedAttendees > 100 RETURN e.name AS EventName, e.expectedAttendees AS AttendeesCount, r.name AS RoomName query.yaml 

26 26 Key Concepts (5/9) Example Explanation: • Sources and Subscriptions: The continuous query subscribes to the event-management source, monitoring nodes labeled as Event and Room, and the Hosted_In relationship to identify which event is held in which room. • Joins: We join event and room data using the eventId and roomId properties to establish a connection between them. • Cypher Query: The query detects events where the expected number of attendees exceeds 100. It returns the event name, the number of attendees, and the room name, which are the relevant data for the catering team. The result is: [ { "EventName": "Tech Conference 2023", "AttendeesCount": 150, "RoomName": "Main Hall" }, { "EventName": "Startup Pitch Night", "AttendeesCount": 120, "RoomName": "Conference Room A" } ] 

27 27 Key Concepts (6/9) Middlewares are essential components in Drasi's architecture that enable pre-processing of incoming changes from data sources before they reach the query engine. Their main function is to transform, modify, or enrich the data as needed, facilitating tasks like value normalization, applying mappings, or adding calculated fields. Functionality of Middlewares: • Data Transformation: Middlewares can modify incoming data to meet the specific needs of the application. For example, they can change the data format or merge multiple fields into one. • Data Enrichment: They can add additional information to incoming data, such as calculations based on existing data or inserting external data. • Normalization: Middlewares help standardize data values, ensuring all follow a consistent format. apiVersion: v1 kind: ContinuousQuery name: catering-alert spec: ... query.yaml drasi apply -f query.yaml Crear drasi list query Listar drasi delete query Borrar 

28 28 Key Concepts (7/9) Types of Middleware • Unwind: Used to break down a nested array of values within the properties of a node or relationship, creating new top- level elements in the graph. • Map: Allows remapping an incoming insertion, update, or deletion from a source to a different operation for another entity, facilitating the modification of the data flow between different entities. Practical Example: Unwind Middleware Imagine room booking records include an array of "expected attendees" with details about each group of attendees. The Unwind middleware can break this array into individual "Attendee Group" nodes, each with its own number of people, group type (e.g., VIP, regular, etc.), and special requirements. This enables more precise management of resources needed for each specific group within an event. Practical Example: Map Middleware Suppose you have a record of changes in the number of attendees, which is only stored as insertions, but the system only needs the most recent value to trigger alerts. The Map middleware can remap the record insertions to updates on an "Event" node, ensuring only the current attendee count is retained. This optimizes memory and processing usage, allowing the system to quickly react to changes that exceed the predefined threshold. 

29 29 Key Concepts (8/9) Middleware's in Drasi are configured using YAML files, where their types, names, and specific properties required for their operation are defined. This provides flexibility and adaptability in data handling, catering to the dynamic needs of event management. apiVersion: v1 kind: ContinuousQuery name: catering-alert spec: mode: query sources: subscriptions: - id: event-management nodes: - sourceLabel: Event - sourceLabel: Room relations: - sourceLabel: HOSTED_IN joins: - id: EVENT_TO_ROOM keys: - label: Event property: eventId - label: Room property: roomId middleware: - name: extract-attendees kind: unwind Event: - selector: $.expectedAttendees[*] label: AttendeeGroup key: $.groupType relation: HAS_GROUP - name: latest-attendee-count kind: map Event: insert: - selector: $ op: Update label: Event id: $.eventId properties: eventId: $.eventId currentAttendees: $.expectedAttendees query: > MATCH (e:Event)-[:HOSTED_IN]->(r:Room) WHERE e.currentAttendees > 100 RETURN e.name AS EventName, e.currentAttendees AS AttendeesCount, r.name AS RoomName 

30 30 Key Concepts (9/9) Reactions Reactions in Drasi are components that process changes in the results of one or more Continuous Queries and act upon them. The specific action depends on the type of reaction being used. Currently, we have reactions available for: AWS EventBridge, Azure Event Grid, Azure Storage Queue, Debezium, Drasi Debug, Drasi Result, Gremlin Command, SignalR and Stored Procedure. apiVersion: v1 kind: Reaction name: spec: kind: queries: : ... properties: (reaction kind specific fields) reaction.yaml drasi apply –f reaction.yaml Crear drasi list reaction Listar drasi delete reaction Borrar 

31 31 Use Case I (1/10) Event Management in Conference Centers This example is a continuation of the Use Case I defined earlier (page 13). Prerequisites • Docker. • Kind. • Visual Studio Code + Drasi extension + Kubernetes extension. Drasi Installation • Steps available depending on the environment you use. In my case, I am using Kind. To install Drasi, I use the -- local flag; this way, I don't need to connect to the online image registry. • Run the quick test to ensure Drasi is functioning correctly. Deploy and configure SQL Server on the Kubernetes Cluster kubectl create namespace usecase-drasi-one kubectl get namespaces --no-headers -o custom-columns=NAME:.metadata.name 

32 32 Use Case I (2/10) • We clone this project: https://github.com/jmfloreszazo/drasi_detect_changes_database • We use the folder usercase_one. 

33 33 Use Case I (3/10) • We apply the deployment: kubectl apply -f sql-server-deployment.yaml • We check the status of the pod; it may take a few seconds (depending on your system): kubectl get pods -n usecase-drasi-one • We check the node's IP to ensure everything is correct: kubectl get service sql-server -n usecase-drasi-one 

34 34 Use Case I (4/10) • We use a port-forward as a temporary solution (only for development or testing): kubectl port-forward service/sql-server 1433:1433 -n usecase-drasi-one • Finally, we can connect to localhost on port 1433 using any tool you prefer to work with SQL Server. • We create a new database and add the content: db-template.sql 

35 35 Use Case I (5/10) • We deploy a queue in Azure Storage Account and save the connection string. • Or we deploy in Azure EventGrid. You have both files in the directory to execute whichever interests you the most, but in this case, you must choose the schema as CloudEvents. 

36 36 Use Case I (5/10) • We deploy a queue in Azure Storage Account and save the connection string. • Therefore, we have a data source (Source), which is a SQL Server in our local K8s, and as a reaction (Reactions), it will send the information to our Azure Storage Account (available reactions). With the infrastructure deployed and functional, it's time to work with Drasi. • We create the source YAML: my-source.yaml • We apply the source: drasi apply -f my-source.yaml 

37 37 Use Case I (6/10) • We check the status of the source: drasi list source 

38 38 Use Case I (7/10) • We create the reaction YAML: my-continuous-query.yaml • We apply the reaction: drasi apply -f my-continuous-query.yaml • We check the status of the reaction: drasi list query 

39 39 Use Case I (8/10) • We create the reaction YAML: my-reaction-az-eventgrid.yaml • We apply the reaction: drasi apply -f my-reaction-az-eventgrid.yaml • We check the status of the reaction: drasi list reaction 

40 40 Use Case I (9/10) • Now we execute this query: INSERT INTO Events (eventId, name, expectedAttendees, eventDate) VALUES ('ev004', 'Drasi Conf 2025', 120, '2025-04-05'); • We check if the continuous query is working: Author's Note Note that in version 0.2.0 of Drasi, we currently have an option that shows what is happening with our continuous query. 

41 41 Use Case I (10/10) • And finally, we check if the event is indeed in the EventGrid, which in my case I have forwarded to an Azure Storage Account: 

42 42 Use Case II (1/3) Temperature Sensor (IoT) This example demonstrates how an IoT application calculates the average temperature of a device and sends it, this time, to the debug reaction so you can observe how it works. Steps • We use the folder usercas_two. • Execute: db-template.sql • Crate the origin: my-source.yaml • Add the continuous query: my-continuous-query.yaml • Set the reaction: my-reaction.yaml • Register the ports in order to view the portal: kubectl port-forward -n drasi-system services/iot-tracking-debug-gateway 8080:8080 • http://127.0.0.1:8080/query/iot-tracking-query-avg-last-30s 

43 43 Use Case II (2/3) 

44 44 Use Case II (3/3) • We execute the loop that generates telemetry and re-enter the debugger: