Concurrency

Even with SQL databases you have to deal with the fact that the web app UI is showing the item as available to multiple users, but it should let only the first one book it. This is not special to the MERN stack.

The simplest approach is to have a collection of bookable items, with a booked field. When booking an item you'll use an update() to set booked to true. In the update, in addition to the item ID in the filter, you'll add a booked = false criterion. If it fails (saying such a record doesn't exist), it means someone else has grabbed it, and show a message to the user.

For a more generic solution where you want to prevent overwrites, many people use a version field which is updated every time the document is updated. For MongoDB, an ObjectID is a natural choice for the data type of this field. When updating a document, the caller has to supply the value of the version field from the find() call, and handle a failure as a conflict.

Security

1. Use SSL - this is straightforward using Node.js using the https module. You'll find tons of tutorials on the net on how to do this.
2. When writing the backend APIs, never assume that it's only your front-end that calls the API. For example, don't skip validations. Just don't trust the caller.
3. You don't need to worry about two of the top the top web app vulnerabilities according to OWASP: SQL Injection (since MongoDB does not use SQL), and XSS (since React does not use HTML templates, provided you avoid dangerouslySetInnerHTML()).
4. As for the rest of the common vulnerabilities, take a look at the OWASP cheat sheet and follow the suggested How to Avoid sections.

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.