Comment by Siddarthan Sarumathi Pandian on "Developing an online bookings web app with MERN stack?"

To build a transaction system like yours, you need both atomicity and concurrency security. As long as you're dealing with a single collection, you should be fine.

Building on top of Vasan's answer, something like:

db.collectioname.update(
    {'available' : true, 'seatId' : 'xxx'},
    {$set: {'available' : false, 'transactionID' : 'xxxx'}}
);

would suffice in a simple environment.

However, most booking systems involve mutiple collections in real life. You would need database level locking in that case. If that's your use case, I am afraid, using SQL would be a better solution for this part of your product. Most applications anyway these days need both a SQL and NOSQL database.

Thanks, Sid, you've got a very valid point. Paraphrasing:

Atomicity means "all or nothing". For example, if after the resource is booked, the user can't be billed, we need to cancel the booking. Better still, the booking should't succeed if billing failed.
Atomicity is a bigger deal (as opposed to concurrency) when dealing with MongoDB, as compared to ACID databases. In ACID databases, you can combine the booking and billing in one transaction and make the whole thing fail if any of them fail.
When the multiple things that need to be done for consistency are within your database (multiple collections), an ACID database with transaction ability works great.

But In real life, things like payment are done asynchronously (by payment gateways) and you can't do it in a transaction (or lock the entire db in MongoDB while waiting for the gateway to send you the result). You need to create rollback or cleanup mechanisms in your own code.

Search Hashnode