I have four API calls pertaining to payment processes that requires updating multiple collections. Suppose I have a hypothetical cinema website where the following collections will be updated on each payment
-
Movie collection (if all tickets are purchased for specific movie, then cancel further booking)
-
Tickets collection (email customers as reminder for purchasing tickets)
-
Customer collection
-
Cinema Hall collection (if houseful then cancel further booking)
Now when a customer purchases a booked ticket via Stripe checkout process, the API call in the backend will update tickets status, customer booking, movie status, and increment cinema-hall seats
At the moment the API call does the following
i) Create new payment
await payments.insertOne()
ii) If payment successful then update tickets
await tickets.updateOne()
iii) update customer
await customer.updateOne()
iv) update movie
await movie.updateOne()
v) update cinema hall
await cinemaHall.updateOne()
In the pseudocode shared above, there are a few problems, suppose that payment is successful, and ticket collection is also updated, if for some reason movie collection update fails, then I will have a partial insert and update operations instead of “all or nothing” approach. For this purpose Transactions seems a better fit as current API deals with critical payment functionalities. I went through Transactions docs and the following statement caught my eye
In most cases, multi-document transaction incurs a greater performance cost over single document writes, and the availability of multi-document transactions should not be a replacement for effective schema design.
Which begs the question that for recurrent payments operations, will transactions have an effect on my application performance in the long run?
Thanks