Hi @rahulrakesh.
We want to highlight an important caveat of how the fwitter example performs updates to statistics fields, such as the number of likes, and therefore to how you may implementing your application.
This is an anti-pattern. It is not scalable, and will quickly run into write-contention errors
In such a query, you are both reading and writing to the “fweet” Document. That means that any other query that writes to the same Document – or even read that Document while writing to something else – can cause contention with this one. Contention can easily happen if there are only a handful of transactions a second, which is clearly not scalable.
All requests in Fauna are transactions. Fauna’s strict serialization rules ensure that transactions are handled in the correct order, but it also limits the rate at which concurrent updates can be made. Here’s a recent discussion about how multiple requests to update the same document can lead to contention errors. Transaction was aborted due to detection of concurrent modification - #11 by ptpaterson
High volume, concurrent updates on single records classically lead to high contention within all databases. Fortunately, there are schema design techniques that avoid this problem. In order to actively increment a “metrics” document or field as part of mutation, the safest route is to aggregate in “chunks” outside of your document, thus avoiding contented writes.
This comes up a lot, so we are pulling together a more complete example for how to do this at scale. I wanted to be sure to update your post now, to give a word of warning. We’ll update this ticket with additional information when we can.