Decoupled Workflow State Management approach for a Loan Origination System

Community Support
1

In the context of designing a Loan Origination System, would it be advisable to implement a decoupled workflow state management architecture? Specifically, this approach would involve utilizing a custom database table to track and manage the state of each loan application. The system would trigger various temporal activities based on the application’s current state.

This approach is being considered due to the dynamic nature of loan application processes, where the state of an application might not follow a linear progression. For instance, a loan application might revert to a previous state, skip states, or advance based on evaluations made by a Business Rule Engine.

Could you validate whether this solution is both technically feasible and aligned with industry best practices? Additionally, what potential challenges or benefits could arise from implementing this decoupled state management approach? ( FYI the Database used is Postgresql and the Java-sdk for the Temporal is used. )

2

You don’t need an external DB to track state with Temporal. Temporal workflows are already stateful and make tracking state trivial. You still need a database for storing loan related and historical data. But you don’t need it to track the loan state.

Temporal workflows are expressed as code; this makes implementing any dynamic requirements trivial.

Could you validate whether this solution is both technically feasible and aligned with industry best practices?

The industry is not yet fully aware of Durable Execution. And its current “best practices” are obsolete once you start using it.

Loan origination is one of the common use case for Temporal. See for example: Building Home Loans 10x Faster with Temporal at ANZ | Temporal Technologies