I'm developing a online bookings web application using MERN. My main concerns are:

  1. Concurrency (like booking a particular item by multiple users at the same time)
  2. Security (web application security)

Can somebody elaborate how should I approach these two concerns?

Write your answer…


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.


  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.
Spot On1

For security i would like to add JWT tokens .. Pretty easy to implement in NODE and provides another level of security against data tampering .

Reply to this…

Hashnode is building a friendly and inclusive dev community. Come jump on the bandwagon!

  • 💬 A beginner friendly place

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 >500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Register ( 500k+ developers strong 👊)

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:

    {'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.

Show all replies

I would suggest to read more about distributed systems first..then research around how you can do asynchronous communication with message passing between your "services" plus you would be better off adopting CQRS and event sourcing. Try avoid doing in place update which would force you to use a distributed lock..

Reply to this…