Whether Activity chaining can be enabled before Write to Data Store entity, is it good practice?

Question

Hi All, 
 We have an application, where users can book the seats before going to office. Currently application working like - If user A books seat 100 for Date: 20-May-2023 and user B cannot book the same seat 100 for same day Date:20-May-2023 here, if seat 100 is already booked by other user than we are not displaying the seat 100 value in dropdown. 
 We got one issue in production that, same seat 100 is booked by user A and B for same day 20-May-2023 at the exact time which is observed in process variable. How to handle this to avoid booking same seat for same day? 
 We are calling process on click of Book button, here in process model activity chaining is enabled before Write to Data store entity. My doubt is whether this activity chaining causing this issue? Please suggest if any solution is available.

Mike Schmitt · Answer

Is the user activity happening within a process, or from like a Site / Record form where you're calling the process asynchronously? 
 Generally I'd suggest that you DO want chaining, which is usually the only way to guarantee that the refresh behavior following the user activity will cause the user to immediately see the results of the just-run process on-form. 
 To solve this race condition (i.e. assuming 2 users are about to book the same single-remaining seat within a few seconds of each other), you can add a query in-process just before the WTDS node, to do one last check that the seat is not yet booked, and if it HAS been booked (i.e. user B missed out to user A by 2 seconds), you follow the script task node with an XOR node which routes a different way, writes an error message to a designated PV, quits the process without writing anything, and the interface loads the error message as part of its ONSUCCESS parameter ("sorry, someone has already booked that seat while you were waiting around", etc). 
 I've tested this sort of setup where 2 people intentionally try to click the action simultaneously, and the process is still fast enough that one of them beats the other to it - so it's suitable for >99.9999% of real-world uses for handling this race condition.