Definition

Triggers are rules based on relative behavior between events that one can configure on Doctor Droid platform. These triggers can be useful to notify you with an alert when any of these critical steps is impacted.

A trigger can be applied to any transaction that you set up on the platform.

Why Triggers?

Consider these use cases below, where there’s a need for stateful tracking needed:

1. In a data processing pipeline, you can set up a % or count-based failure rate above which you should get an alert.

2. In an order fulfillment product, you can setup ETA based alerts for every order on a locality level or for its average in dinner time on an hourly basis.

3. In a login OTP flow, you can get notified in real time if your SMS delivery success is dipping.

4. In a gig workers payout state machine, track the speed of transfer and get notified of failure rates and patterns like specific recipient banks failing.

Currently, you have two alternatives:

• Track count(E2)/count(E1) — A success rate here will be fairly accurate if most of your transactions close in a time window that is much smaller than an evaluation window.

  • E.g. If your process (from step 1 → 2) takes 3 seconds to complete, the ratio will fairly explain the value. But if the tnx takes say, 1 minute, then on a 5-minute window, there’s a potential of ~20% error margin as the count(E1) and count(E2) are not connected.

• Process the value of E2/E1 at the E2 step in the code and then plot the metric of success rate/transaction time.

  • The risk here is that in case the code didn’t reach till E2 or takes too long, you wouldn’t get proactive visibility on it.

Types of Triggers

Consider an example where you’re a video recording tool and you want to track if your recording → processing workflow is happening perfectly fine.

1. Per Event

   Let’s say, there are certain types of cases where you want to be particularly perfect. Say a high-paying customer or a specific type of video.

   This is for generating an alert when E2 is delayed by more than 'X' time interval than E1.

   It will generate alerts for each such instance and notify you of the E1 payload for which it happened. This type of trigger is useful when you need to know if “every” customer had a good experience.

   

2. Aggregated Events

   This is for use cases when you want to get insights on aggregate behavior.

   For instance, in case you want to get notified if more than 1% of your users are impacted for this transaction or if the p99 for this transaction is exceeding a certain value in the last 5 minutes.

   

Additional Filters

1. Filter on attributes in either of the events so that only the events satisfying that filter are being considered for the trigger rule.

2. For the aggregated events trigger, you can choose to consider only those cases where the secondary event got missed or only got delayed.

   

Conflict management:

In case you send duplicate events with the same group key, we consider the first event while creating transactions or reviewing trigger rules.

In case you can think of a use case where you want to set up a trigger, sign up here.

Further Readings:

What is a transaction on the Doctor Droid platform?

What is an entity on the Doctor Droid platform?