Approaches for Start and Resume Journey for User Onboarding to Platform (Part II)
This article is the continuation of Part I. I would recommend reading Part I to have some context on this problem. Below is the reference,
We discussed 2 approaches in Part I which are fine for the app having low to moderate traffic. In this article, we are extending the previous 2 approaches to allow the application to handle more traffic and provide increase code re-usability which is important for the big-size application.
Approach 3: This approach uses concepts from graphs to model this problem.
Taking the idea from graphs and using some terminology we can allow users to resume their journey. Here, nodes in the graph represent steps that the user has to perform. There can be different types of nodes like executed node, unexecute node, completed and terminated node. To know the status of the application, we can create one collection as application state logs and there we can store the metadata about the application and its status.
Once a user completes the step, some metadata about the step is stored in the application state logs like the finished step as an entry in the collection/table in the database.
For rejected applications, there we can store Terminated step as an entry in application state logs.
For steps that the user dropped in between, there will be one log stored in the application state logs with status as started.
Now, we simply have to define the process or sequence of steps in order that we need the user to perform. When a user starts the application, we can check whether there are any logs in the application state logs, and based on that we can decide whether we have to resume his last journey or create a new journey.
This check simply requires one network call to the database as we are now storing the state of the application in the database as application state logs.
Let’s say a current user is visiting the platform for the first time, then we can simply start the onboarding journey from the start. By simply checking state logs, the application understands the next action.
For returning users, there will be some logs stored in the application state logs, and based on those logs, the orchestrator application will check the defined steps in the onboarding process and check the status of the step in the previously fetched application state logs.
Here, if the status of the step in the metadata for that step is present and marked as finished then the application can skip the step and check the next step in the process.
If the status of the step is marked as terminated then the orchestrator knows that and simply shows the application rejected page to the user.
If at last log in the application state logs are not terminated and the log of the current step has status like started or not available then the orchestrator knows that it has to execute this step as it is not finished.
Once all the steps are completed then the orchestrator can simply add the completed step as the last step which is an indicator for successfully completing the onboarding application and the orchestrator can simply show a page like your application is under review or something similar to this.
If the user finds that some of the details entered in the previous step are wrong, then navigation from the current step to the previously completed step becomes easy as we simply have to pop the logs from the application state logs until we reach the step which the user has selected.
What are the advantages?
- It only requires a single network call for the orchestrator to decide whether to resume or create a new onboarding process for the user.
- Since we are using a graphing approach, steps can be rearranged in any order without breaking the application.
- Modeling of the problem becomes a lot easier and network calls are reduced to single calls to just find the resume point.
- If the user drops in between then custom logs can be added which will move the user to defined steps and make him redo those steps. (This is a pretty common and import scenario like failed KYC and requires the user to redo KYC as we don’t want to lose him)
- Steps can be shared with other orchestrator applications like we usually see in applications that follow Service-oriented architecture (SOA) or Domain-driven Design (DDD) where code sharing (Kernel code) with other services to speed up the development and avoid feature duplication. Like passport verification, KYC is a pretty common step in finance-related applications where the business rules are the same for these steps for that business.
- Steps can be skipped based on some condition when the user is redoing those steps after navigating back to previous steps.
- Application data can be modeled to a single collection in the case of No-SQL.
- Database design is much cleaner
- The effort required to update or change any steps is comparatively less.
- For rejected applications, Orchestrator can check the last log in application state logs and based on that show the error page or drop page.
Ok, What are the disadvantages?
- For users who selected to navigate to the previous step, they need to redo the next steps after the selected steps in the journey. It can be improved by saving the previously entered details and showing them on the screen to save some time but users still need to go through those steps again.
- Jumping backward is pretty simple by popping the application state logs but that also means the user can’t jump back to the last step where he was before navigating back to the previous step as logs are lost.
- Before working on such an application, new developers need to be aware of the flow so it does have more learning curves compared to approach 1.
When to use approaches 2 and 3?
As we can see approach 3, has its pros and cons. But, for this approach, picking a graph-based finite state machine approach gives more advantages to developers to deliver more releases/features in less time.
Considering the flexibility to change the application and delivery time and effort required to change, we can see approaches 2 and 3 look to be a good option. Decisions can also be made based on the tech stack used to implement the problem.
The End.
