Data base performance flow approach question

I got an app where the user has a way to sell things and add costs of his services.

You can manipulate one of the 5 fields of prices/costs.

From those elements - I display the estimated price/margin split for different people involved.
This is done on the frontend. In the end it is 8 fields I sum up in a different way, depending on people configuration.
The program doesn’t know when the user is done, as it is an autobinding operation.

But here is the problem. Those selected fields should be sum up for a user, creating a pool of his money from all his open sales. But if I updated all 8 fields everytime the user edits the 5 fields he can, I will race a lot of operations which can collide with each other leading to misscalculations.

How would you approach it, in order to provide the user good and dynamic overview of his deal pool?

I have an idea - to allow for changing the fields and display of results on the frontend and somehow schedule a workflow on a backend for current date + 5 minutes, that will update those 8 fields.
This way his deal pool will have just 5 minute delay maximum. But is it the best way, or there is another approach?

Acceptence Criteria:
User sees price calculations dynamically.
Deal pool is up to date dynamically (or can have at least few seconds delay).
There is no additional user action required - like clicking the button.

Have you experienced issues with just using autobinding in production?

This is a valid approach I do use already for an autosave logic with multiple large text fields. If the fields are just numbers I don’t see how autobind can cause race conditions.

Though it would be justifiable UX to have a delayed save.

Got it.
The racing condition was the flow of:
When editing field 1 - schedule backend workflow on X elements.
The X is varied, depending on who is the person connected to which fees. So if some poeple edit the fields like they were working in Excel, so fast jumping with TAB, then same fields have impact by multiple workflows and this is what is racing condition.
People use those fields like an estimate calculator, so they may change ex. input up to 10 times within 3-4 seconds and want to see the results asap.