Assume an event ticket website where to handle volume and concurrency, tickets are distributed on different servers and database.
For example, on "server1" 10 tickets are left and on "server2" 5 tickets are left. If at the same time "User1" (whose request is forwarded to server1) send a request to book 12 tickets, "user2"(whose request is forwarded to server2) send a request to book 3 tickets. "User3" (whose request is forwarded to server2) send a request to book 2 tickets.
Although 15 tickets are available in the system but server1 will tell user1 that 12 tickets are not available but user2 and user 3 aill be able to book their tickets. This will become unfair for user1.
Any ideas about how to handle this situation?
You can't do this with each server having it's own ticket count. You will need to either have a central database that every server can access for the source of truth, or you will need a distributed database with a distributed locking mechanism (which at it's core is the same thing, just with a distributed cache for reads).
I've used decent distributed lock managers based on Apache ZooKeeper and Redis, but you should probably do your own research to find what fits your particular needs, but they are a good place to start.