3

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?

Prakhar Avasthi
  • 51
  • 4

1 Answers1

1

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.

Rob Conklin
  • 8,806
  • 1
  • 19
  • 23
  • Can you explain a little more about how distributed locking is at it’s core similar to a distributed cache for read? – Prakhar Avasthi Oct 18 '18 at 12:54
  • The distributed database has the same issue in that there is still a single point of scaling that will limit your throughput. You are likely better off scaling up your central source of truth and handling your locks better in that centralized database than trying to distribute something as atomic as ticket-counts. – Rob Conklin Oct 18 '18 at 15:02
  • I could see doing something interesting like creating a lock-per-seat instead of lock-ticket-count to distribute it better. You would need some good speculative locking algorithms to find the seats the client wants (all together for example), but it's definitely doable. – Rob Conklin Oct 18 '18 at 15:04
  • I like the idea of distributing atomic ticket-counts. But wouldn’t the problem still arise because when user1 requests for 12 tickets and server1 have ticket count as 10 and server2 have ticket count as 5, wouldn’t server1 refuse the request. Or server1 should ask other server for their count if the requested tickets are greater than its ticket count? – Prakhar Avasthi Oct 18 '18 at 18:29