Reactive Process
Examples
Description
A component that autonomously runs a processing routine as soon as data that already resides in the system changes: when a record is created, edited, or deleted, the component detects it and reacts, without a user operating it step by step and without a schedule involved. It takes the change as its trigger, applies some logic —deriving new data, propagating a consequence, validating an invariant— and produces a result: new data, corrected data, or the activation of another process.
The canonical case: as soon as a new customer appears in the customers table, automatically create their access account. Nobody schedules that creation or requests it by hand; the change in the data triggers it. In the software industry it corresponds to three materializations of the same pattern —the system observes itself and reacts—: database triggers (the database runs logic on an INSERT/UPDATE/DELETE), change data capture (an observer reads the transaction log and emits an event for each change), and domain events (the application publishes a business event when its state changes, and another component consumes it).
What shapes this component is the how (autonomous processing of internal data, triggered by a change in that data), not the what: it does not fix which reaction it runs, just as a Data Manager does not fix which entity it administers. Its close relative, the Scheduled Process, shares the territory of internal autonomous processing but differs in its trigger: that one runs when the clock says so; this one runs when the data changes.
Mandatory capabilities
- Detects a change of state in data that already resides in the system (creation, editing, or deletion of a record)
- Is triggered autonomously by that change, without a schedule and without human intervention in its steps
- Runs reaction logic based on the change: deriving data, propagating a consequence, validating an invariant
- Operates in the background, without occupying or blocking the user's interaction with the system
Additional capabilities
- Condition filter: reacts only when the change meets a certain condition (e.g., "only if the new customer is a business"), not indiscriminately to every change
- Chaining: its reaction in turn triggers another process or notification, propagating the consequence of the change
- Result delivery: communicates the result proactively (notice that the account was created, alert of a violated invariant)
- Trigger logging: logs each activation (which change triggered it, when, with what result) for auditing and monitoring
- Idempotency and retries: guarantees that the same change does not produce its reaction twice, and retries if the reaction fails
Boundaries
- Does not react to an external event. The change that triggers it originates inside the system (one of its own records changed). If the reaction is set off by a notice that arrives from outside —an incoming HTTP notification, a webhook—, that is external input and belongs to an Exposed Service, not to a Reactive Process. The distinction is the origin of the trigger: internal, not external.
- Is not triggered by the clock. If the routine runs on a schedule (every night, every hour) rather than in response to a specific data change, it is a Scheduled Process.
- Does not bring in data from outside the system. It operates on the data already inside. If it fetches data from an external source, that is an ETL or a Scraper.
- Does not involve human decisions in its steps. If the processing stops so that a person can approve or reject, it is an Approval Workflow.
Information flow
A change of state in internal data (creation, editing, or deletion of a record) that acts as a trigger, detected by the system itself
The result of the reaction: derived or corrected data written to the system, or the activation of another process or notification
Variants
- Database trigger: the database itself runs the logic on an INSERT/UPDATE/DELETE on a table.
- Change data capture: an observer reads the database's transaction log and emits an event for each change, which the application consumes and processes.
- Domain event: the application publishes a business event when its state changes ("customer created"), and a subscribed handler reacts.
Typical dependencies
- The system's data repository (Database), whose changes it observes and which it reads from and writes to
- A change detection mechanism (database triggers, change data capture connector, domain event bus) that governs when it is triggered
- Business rules that define the trigger condition and the logic of the reaction
- Notification System, when the reaction is communicated proactively
Mapping to the Digital Board
| Section | Relationship | Notes |
|---|---|---|
| Manual Update | No | No operator writes data step by step; the reaction is autonomous. |
| Automatic Update | No | It does not bring in data from outside the system; it reacts to changes in the data already inside. |
| Data Concepts | Always | It always reads the entity that changed and/or writes the one it derives as a consequence. |
| On-Demand Outputs | No | It does not respond to an external request; it triggers on its own, from the change in the data. |
| Automatic Outputs | Optional | When the reaction is communicated proactively (account-created notice, alert of a violated invariant). |
| Autonomous Processes | Always | It is its essence: the autonomous reaction that runs without human intervention, triggered by a change in internal data. |