What is Doctor Droid?

Doctor Droid is a stateful events monitoring tool that helps you capture data on how your backend is affecting customer experience. Doctor Droid then lets you setup monitors by joining different events together and generate alerts based on their own or relative behaviour to each other. This enables you to detect and diagnose production issues faster, much before customers or business teams escalate them.

Introduction to Data Model

Doctor Droid relies on an "event-based architecture" and allows joining of events together using common keys that unlocks the ability to model your events as a state machine and lets you monitor transitions between them.

Our event-based architecture is built on three key concepts: Events, Event Type, and Attributes.

Events

Event is a step in a product workflow that has a unique key that represents the context of that workflow like an order_id or transaction_id. An event can be used to describe almost anything like:

• Order placed by a customer
• Webhook callback from the payment gateway
• A user levelling up in a game

Event Type

Event Type tells what the step is in your workflow. It is a simple string. For the examples mentioned above, you can use the following:

• Order_Placed
• Webhook_Callback
• User_Level_Changed

Attributes

Attributes give metadata about the event. Mostly they are used to tell real-time information at the time of the occurrence of the event. Every event must have an attribute that identifies the entity of that event and comes in other events which are part of the same product workflow. We call it the group key.
For examples mentioned above, you can have the following attributes (the bold one being the group key):

• order_amount, items, delivery_city, order_id
• payment_status, transaction_id, funding_instrument
• start_level, end_level, current_points, user_id

These terms should help in navigating through this documentation and the tool more easily.