Concurrency in NoSQL I am planning on writing a webapp where a user can buy an object from a seller.
Also I would like to outsource the payment so that I don't have to deal with the payment process myself. I was wondering how the following scenario would work out in a NoSQL Database like MongoDB? 


What happens exactly if a user buys an object, but at the same time
the seller deletes that object, because he does'nt want to sell it
anymore?
How do I deal with it in a NoSQL Database like MongoDB?
Or do I have to do it in the application level? 


I saw an example that a big travel company uses MongoDB, so my guess is that scenarios like that should be possible to fix, I just don't know how. Should I stick with an SQL-Database like PostgreSQL?
I suggest you read following documentation about MongoDB first. This is a very broad question for a forum like this. Unless somebody analyze your application requirements in details it is not possible to give a precise answer.

Broadly in MongoDB ACID property is respected for a single document and NOT for multi document. 

Does MongoDB support ACID transactions?

Yes, but in a limited sense. MongoDB supports ACID transactions at the document level; today MongoDB does not support multi-document transactions. For many but not all applications, this is sufficient because data for a record tends to be managed as a single document. Like most databases, MongoDB uses write-ahead logging to an on-disk journal to guarantee write operation durability and to provide crash resiliency.

The distributed nature of MongoDB necessitates additional consideration beyond ACID regarding consistency and availability. MongoDB automatically maintains replica sets, multiple copies of data that are distributed across servers, racks and data centers for high availability ( see How does MongoDB ensure high availability? ) MongoDB is strongly consistent: all reads and writes are applied to the primary member by default. ( See How does MongoDB ensure consistency? ) Write operations are automatically applied to all replica set members. You can configure each write to return after success on the primary, on multiple set members, a majority of set members, or all members. Reads can be applied to the primary member, to secondary members if the primary is unavailable, to specific members exclusively (for workload isolation), or to the nearest secondary based on ping distance. You can configure your reads and writes to achieve the consistency and availability required for your application.

Read more about concurrency here.