In an application I'm developing we have integrated with a third party api. One of the use cases consists of a user of our system filling out a form and submitting it. This results in us mapping the form to an api request model and posting it to the third party api. This starts an external process, the details of which aren't relevant. We do get a response with a unique ID for the created process though, and when we get this, we create a business entity that models the started process so we can track and update it, etc. It needs to be noted that each user (account) can only start this process once (this is enforced by checking if the account has any associated process).The problem we're having is that if a user double taps submit or reposts, there is a chance that they will invoke the start of another process before we've had time to get the response from the third-party api and coupled the process entity to the user account. The third-party api does not care if two requests are identical.We're looking for a neat way to sort of lock the account so it cannot be used to send more requests to the third-party until the use-case is complete and we get a non-successful response. One very hacky way to accomplish it would be to as soon as the use case is initiated, save a dummy entity with some gibberish string as it's id in the database and associate it to the account. When we get our response from the third-party api, we can delete the dummy and proceed as normal.Similarly we could allow for creation of the process entities with no id from the third-party, and then we update it when we get a successful response. This feels slightly cleaner, but it would be nice if we could avoid loosening the constraints on the entity (this ID should never change and in the model it's considered to be a constant unique identifier). This could very well be me being pedantic, but if there are other paths I would like to explore them.If it's relevant, the user submits the form as a HTTP POST, we process it server-side in an ASP.NET application using Entity Framework as an ORM and we post the request to the third-party using a client that internally uses a standard .NET HttpClient.It might also be of note that even if we do detect that a duplicate has been created, we cannot simply delete the row and notify the third-party (without considerable business overhead)
Prevent creation of multiple entities
design;data integrity