What a "DAG" Has to Do With a Wellness App
- Fido Sir
- Aug 17
- 7 min read
Hey everyone,
You know that feeling when you're using an app, and everything just… works? You tap a button, and the right thing happens instantly, even if it feels like a million things are happening at once.
Well, as a part of the team that built a comprehensive wellness app, I can tell you that making that magic happen is the result of a lot of careful planning. And one of the most important tools we used is something called a Directed Acyclic Graph, or DAG.
Before you close the tab, I promise it’s simpler than it sounds!
Building a wall happens step by step. First, bricks are laid, then cement, wiring, plaster, and finally paint. Each step depends on the one before it. That’s exactly like a DAG: a chain of tasks with a clear order and no going back.
Let me explain it using a wellness app as an example.
Our consultation app is more than just a place to book a doctor. It is a full-fledged wellness platform. We have three types of users:
Patients who can book consultations, view their health logs, and check their device data (like a CGM or smart ring).
Doctors who travel to different locations and need to manage their schedule and patients.
Organizers who set up the camps where the doctors practice and manage walk-in patients.
Think about all the things that have to happen at the right time:
An organizer schedules a camp.
An admin has to approve it.
The doctor’s calendar has to update.
A patient has to see the right doctor based on their location.
A booking happens (or a walk-in is added).
The prescription is written and stored.
The doctor's pay and the organizer's share are calculated.
And all of this has to happen while a patient is also tracking their steps and glucose levels in real-time (if he has bought a CGM or smart ring).
It's a lot, right? If just one of these steps messes up, the whole system could fall apart.
The Solution: We Used a DAG as Our Blueprint
A DAG is a specialized kind of flow chart that has one crucial, unbreakable rule: there are no loops or cycles. Imagine a series of boxes connected by arrows. Each box is a "task," and the arrows show the "dependencies" - meaning one task can't start until the one before it is finished.
The "directed" part means the arrows only go one way (e.g., you can't book an appointment before the doctor's calendar is updated). The "acyclic" part means there are no loops, so you won't get stuck in an endless cycle.
Here’s how we applied it to our app's workflow:
Step 1: The Camp Scheduling Flow
The first part of our DAG was a simple, single path.
Organizer schedules a camp.
Admin approves it.
Doctor’s calendar gets updated.
The camp for that doctor gets added in the app and is visible to patients for booking.
This ensures that the doctor's calendar is never updated with an unapproved camp. Simple, right?
Step 2: The Booking Flow
This is where the magic of parallel processing comes in.
A patient can book a slot OR an organizer can add a walk-in.
Our DAG knew that both of these actions lead to the same next step: confirming the booking.
Once the booking is confirmed, the DAG splits into multiple paths:
One path immediately updates the doctor’s dashboard.
Another path updates the organizer’s dashboard.
At the same time, the booking appears in the patient app as an upcoming appointment.
All these tasks happen at the same time. The app doesn't have to wait to update one before updating the other, which makes everything feel super fast for the doctor, the organizer and the patient.
Step 3: Post-Consultation
This is my favorite part because it shows how many different things can be triggered by a single event. When a doctor writes a prescription in the app:
The DAG starts a new set of tasks, all running at the same time:
The prescription is loaded into the patient's history. This is a critical step, as it allows any other doctor to access the patient's full medical history later on.
The doctor's consultation fee is calculated.
The doctor's commission is calculated.
The organizer's share is calculated.
And finally, both the doctor’s and organizer's dashboards are updated in real-time.
Because of the DAG, we know that the revenue is only calculated after a valid consultation and prescription are created. And all the calculations happen simultaneously, so everyone gets their real-time updates without any lag.
And What About the Wellness Tracking?
The wellness tracking features (like step logs, meditation, water logs or device syncs) are part of a completely separate, always-on DAG.
The moment your smart ring syncs via Bluetooth, a process starts in a different part of the system.
Data on your steps, heart rate, Sp02, temperature and sleep flows into your profile.
For CGM users, your glucose readings are also synced in real time.
That data is then used to update the beautiful graphs on the user's dashboard.
This pipeline runs continuously, independent of all the booking and consultation stuff. But if a doctor wants to see your sleep data during a consultation, that data is already there (in patient app), ready for them to access.
The Bottom Line
A DAG might seem like a complex technical term, but for us, it was the perfect blueprint. It allowed us to manage a huge number of moving parts without things breaking. It ensured that every action happened in the right order, and it made sure our app felt incredibly fast and responsive by allowing different tasks to run in parallel.
Technical Deep Dive: The DAG Behind the App
While the blog post above explains the concept in simple terms, let's get into the nitty-gritty of how we would technically implement this using a DAG structure.
In a real-world scenario, this would likely be orchestrated using a tool like Apache Airflow. Each "box" in our flow chart is a Task (or Operator in Airflow terminology), and the overall flow is a DAG. The arrows are the dependencies we define in our code.
The DAG visualizes all the tasks (nodes) and their dependencies (arrows), ensuring that every action happens in the correct order and that multiple tasks can run simultaneously where appropriate.
Explanation of Phases and Nodes
Phase 1: Scheduling & Availability 🟢
This is the initial, linear part of the process where the doctor's schedule is created. It's a straightforward chain of events.
A: Organizer Schedules Camps: An organizer initiates the process by logging camp dates and locations.
B: Admin Approves Camps: The scheduled camps are sent for admin review. This task is dependent on the organizer's input (A).
C: Doctor Calendar Updated: Once approved, the doctor's calendar is updated with the new camp schedule. This task can't run until the admin approval (B) is complete.
Phase 2: Booking & Consultation 🔵
This phase focuses on the patient-doctor interaction, from booking to consultation. It's a critical part of the user journey that needs to be seamless.
D: Patient Searches for Doctor: This is the starting point for the patient. The system uses the updated calendar data (from C) to show available slots to the patient.
E: Patient Books Slot / Organizer Adds Walkin: This node represents a key branching point. A slot can be booked by a patient or manually by an organizer for a walk-in. Both actions lead to the same next step.
F: Booking Confirmed: The app confirms the booking, which depends on either of the two booking methods in (E) being completed.
G: Update Dashboards: Once a booking is confirmed, the system immediately updates the dashboards of both the doctor and the organizer. This happens in parallel to provide real-time visibility.
H: Doctor Starts Consultation: The doctor initiates the consultation, which depends on the booking being confirmed (F) and the appointment time arriving.
I: Doctor Creates Prescription: During the consultation, the doctor writes and submits a prescription. This action is the trigger for the entire post-consultation phase.
Phase 3: Post-Consultation 🔴
This is a sophisticated section where multiple parallel processes are initiated by a single event. The DAG forks into three main branches to handle different aspects of the consultation's aftermath.
I → J & K: The completion of the prescription (I) triggers two immediate, independent processes: storing the prescription and starting the financial calculations.
J: Prescription Loaded to Patient History: The prescription is stored securely in the patient's medical history for future access. This is a crucial task for patient records.
K: Calculate Consultation Revenue: The total revenue for the consultation is calculated. This is the source node for all financial calculations.
K → L & M: From the revenue calculation (K), two separate tasks run in parallel to determine the compensation for each party.
L: Doctor Commission: The doctor's share of the revenue is calculated.
M: Organizer Share: The organizer's share of the revenue is calculated.
L & M → N: Both commission calculations (L and M) must be completed before the final dashboard update task.
N: Update Financial Dashboards: The system pushes the calculated commission and share to the respective dashboards of the doctor and the organizer, providing them with real-time financial data.
Wellness Tracking (Always Active) 🟠
This is a separate, always-on DAG that runs independently of the consultation flow. It's a perfect example of parallel, continuous processes within a single application.
O: Log Activities: This node represents the user's manual input of data, such as meals, water intake, or steps.
P: Play Meditation Audio: This task tracks the user's engagement with the app's meditation content.
Q: Connect Bluetooth Devices: The user's CGM or smart ring connects to the app via Bluetooth. This is a critical prerequisite for the next two steps.
Q → R & S: Once a device is connected, two independent data streams begin.
R: Sync CGM Data: The system continuously receives and processes glucose level data.
S: Sync Smart Ring Data: The system receives and processes data like heart rate, sleep, and stress levels.
O, P, R, S → T: This final node is a central hub. It takes data from all wellness tracking sources (O, P, R, and S) and consolidates it to provide a comprehensive, real-time update on the patient's wellness dashboard. This consolidation allows for a holistic view of the user's health. So, next time you use our app, you'll know that a little bit of graph magic is working hard behind the scenes to make your wellness journey seamless and smart. ✨
Comments