Change-Driven Solutions

Drasi simplifies building change-driven solutions by letting you focus on which changes matter rather than how to detect them and process them. This page describes three approaches to using Drasi, from simple change observation to sophisticated dynamic collections. Each approach builds on the previous one, demonstrating how Drasi’s Data Change Processing Data Change Processing The continuous detection and processing of meaningful data changes across systems. Learn more capabilities can be progressively adopted.

1. Observing Changes, where you use Drasi to detect the simple creation, modification, and deletion of data elements in one or more source systems and take some action in response to those changes. This approach is the most similar to existing event-driven and change-detection solutions and is the easiest way in which to use Drasi in place of existing alternatives.
2. Observing Conditions, where you use Drasi to detect when changes in one or more source systems cause some pre-defined condition to be met. These conditions can be simple property constraints, but more interestingly they can describe conditions that include multiple entities and the dynamic relationships Relationship A connection between two nodes in the property graph, representing how entities relate. Learn more that exist between them. Without Drasi, doing this requires the development of a custom service or function that periodically checks for the condition, or which takes multiple source feeds and performs checks to determine when the condition is met.
3. Observing Collections, where you use Drasi to define stateful collections of data elements that meet some criteria, for example all orders that are ready for which there is a vehicle waiting in the curbside pickup zone or all employees in my team that are currently in a location that is at risk due to a high severity incident. Using Drasi, changes to the content of these collections can be used to trigger automated processes or through real-time Reactions Reaction A component that receives query result changes and takes action on them. Learn more to dynamically update application UIs.

Each of these approaches is described in more detail in the sections below. However, it is important to understand that the only difference in these approaches is the degree to which you embrace the capabilities of Drasi. The more sophisticated approaches require you to include more Sources Source A connection to an external system that Drasi monitors for data changes. Learn more ; write richer Continuous Queries Continuous Query A query that runs continuously, maintaining an always-current result set as data changes. Learn more ; and take a greater dependency on Drasi’s Reactions. But they also allow you to push more responsibility onto Drasi, meaning you write and maintain less code.

Observing Changes

Most systems that provide change notifications do so by reporting every creation, update, or deletion of data entities as discrete events. For example:

• A Retail Operations system might report changes to Orders, Products, and Customers
• A Human Resources system might report changes to Employees, Teams, and Vacancies

Database change logs are the most common example–they output details of every record that is created, updated, or deleted. The problem is that these systems generate a fixed set of change notifications with schema defined at design time. Consumers must filter through potentially high volumes of changes to find the changes they care about, maintain state to understand what has actually changed, and call back to the source system if they need additional related data.

This traditional approach makes solutions brittle: the logic to filter and process changes must be written and maintained by the consumer, and requirements changes often require code changes.

Using Drasi to observe these types of changes is trivial without the need for you to write any code, or deploy and manage services to process the source change stream. For example, using the following Continuous Query subscribed to a suitable Source, you would get notified when any node with an Incident label was created or deleted, as well as the before and after version if an Incident was updated.

MATCH (:Incident)

By default, this Continuous Query would return all data for each Incident, but if you want to limit the data to the specific properties required by your solution, you could assign the Incident an identifier (‘i’ in the example) and project desired properties using a RETURN clause:

MATCH (i:Incident)
RETURN
  elementId(i) AS IncidentId,
  i.severity AS IncidentSeverity,
  i.description AS IncidentDescription

Now, with a single Continuous Query and no coding, you are dynamically detecting simple changes and generating custom change notifications on a source system that doesn’t inherently support change notifications. You can use any Reaction to process the observed change in order to integrate with an external / downstream system.

Observing Conditions

More flexible change notification systems allow consumers greater control over which events they receive so they don’t have to take the entire feed and filter it themselves in stream processing systems or in code. In the simplest form this is done using event type and property filters with more advanced systems supporting rules and logical predicates. This allows you to think less about observing low level data changes and more about receiving notifications when desired conditions become true. For example, when:

• an Incident becomes critical.
• an Order becomes ready for pickup.
• a Room’s temperature exceeds 80 degrees.
• the occupancy of a Store exceeds 100 people.

In Drasi, you have access to the rich and expressive Cypher and GQL languages making it trivial to implement condition-based filters. For example, the following Continuous Query generates results when an added or updated Incident:

• has a type property with the value environmental.
• AND has a severity property with the value critical or extreme.

MATCH (i:Incident {type:'environmental'})
WHERE i.severity IN ['critical', 'extreme']
RETURN
  elementId(i) AS IncidentId,
  i.severity AS IncidentSeverity,
  i.description AS IncidentDescription

Going beyond simple property value filtering is also straightforward; Drasi enables you to think in terms of complex conditions that encompass multiple connected elements. For example, the following Continuous Query requires that the Incident have an OCCURS_IN Relation to a Region, which in turn has a PART_OF Relation to a Continent. And that the Continent have an id of ‘NA’.

MATCH
  (i:Incident {type:'environmental'})-[:OCCURS_IN]->(r:Region)-[:PART_OF]->(:Continent {id:'NA'})
WHERE
  i.severity IN ['critical', 'extreme']
RETURN
  elementId(i) AS IncidentId,
  i.severity AS IncidentSeverity,
  i.description AS IncidentDescription,
  r.name AS RegionName

Now, using the rich query language supported by Continuous Query and no coding, you are dynamically detecting complex conditions and generating custom change notifications on a source system that doesn’t inherently support rule-based change notification. You can use any Reaction to process the observed condition in order to integrate with an external / downstream system.

Observing Collections

While Observing Conditions tells you when something becomes true, Observing Collections maintains a living set of items that match your criteria and tells you when items join or leave that set. This distinction is powerful: instead of reacting to individual events, you maintain awareness of an entire category of things and respond to membership changes.

Consider these examples of dynamic collections:

• Curbside pickup queue: All orders marked “ready” where the customer’s vehicle is in the pickup zone
• At-risk shipments: All shipments containing temperature-sensitive goods currently in transit through regions with weather delays
• SLA breaches: All support tickets that have exceeded their response time threshold with no agent assigned, grouped by customer tier
• Delivery opportunities: All drivers currently within 10 minutes of a customer who has an order ready but hasn’t been dispatched yet

Each of these collections spans multiple data sources (order systems, IoT sensors, GPS tracking, weather services) and changes dynamically as the underlying data changes. Without Drasi, building these requires custom code to:

• Poll multiple databases and APIs
• Maintain state about what’s currently in each collection
• Detect when items enter or leave
• Handle the complex joins between disparate data sources

With Drasi, you define the collection as a Continuous Query, and Drasi handles the rest.

Example: Curbside Pickup

A retailer wants to minimize customer wait times for curbside pickup. The solution needs to know which customers are waiting and for how long, combining data from the order management system and the parking lot vehicle detection system.

MATCH
  (o:Order {status: 'ready'})-[:PLACED_BY]->(c:Customer),
  (v:Vehicle {licensePlate: c.licensePlate})-[:PARKED_IN]->(z:Zone {type: 'curbside'})
RETURN
  o.id AS OrderId,
  c.name AS CustomerName,
  c.phone AS CustomerPhone,
  v.licensePlate AS Vehicle,
  v.arrivedAt AS ArrivedAt

This collection updates in real-time as:

• New orders become ready (potential additions)
• Vehicles enter the curbside zone (potential additions)
• Vehicles leave (removals from collection)
• Orders are fulfilled (removals from collection)

A store associate’s dashboard bound to this collection always shows exactly who needs attention, with no polling and no stale data.

What Makes Collections Powerful

Membership notifications: You learn not just that something changed, but specifically that an item joined or left the collection. When a vehicle leaves the pickup zone, you know that customer is no longer waiting–without having to track state yourself.

Cross-system visibility: Collections can span multiple Sources. The curbside example joins order data with vehicle detection data, even though they live in completely separate systems.

Real-time aggregates: Because Drasi maintains the collection, you can build dashboards showing “4 customers waiting” that update instantly as the number changes.

UI binding: Using SignalR or SSE Reactions, applications can bind their UI directly to a collection. The dashboard doesn’t poll–it receives push notifications when the collection changes, showing additions, updates, and removals in real-time.

Change-Enabled Systems

In addition to the three approaches for using Drasi to build change-driven solutions, which are focused on the detection and processing of change in existing systems, you might also consider adopting Drasi if you are creating a system that you want to be a source of change for other systems to observe. Under such circumstances, you might consider Drasi as an alternative to implementing your own change notification solution. Just as most people do not implement their own database, messaging infrastructure, or web framework, using Drasi means you do not need to implement your own change notification solution. Instead, as part of your overall solution, you could provision a Drasi deployment and instruct downstream developers to use it to observe and react to changes from your system. You are freed from a great deal of design and development and the downstream developers get a richer and more flexible way to detect and react to change in your system.