1

I have an implementation where I have one wallet (wallet per client/company) and a number of users belonging to one wallet. I have hundreds of API calls per second for Authorization from users. When I get authorization API calls from users and following activities are done,

  • Lock the wallet belonging to the current user.

  • Make sure validation rules are passed.

  • Wallet has sufficient balance for the transaction to be successful.

  • Update wallet balance.

  • Unlock the wallet belonging to the current user.

There are other calculations, and updates on different tables as well and the total time taken could be anywhere between 500 to 1000 milliseconds.

This works fine when we have fewer users per wallet and fewer simultaneous calls per second from users, belonging to one wallet.

How can I scale this architecture or changes to this implementation so that I can support hundreds of requests per second belonging to the same wallet? The issue is when I have lots of requests per second because of the lock on the wallet requests will be in the queue and they will timeout.

I was reading about event-based systems but here every auth call is sync API call, so not sure how to adapt to event-based architecture.

nandeesh
  • 753
  • 7
  • 16

1 Answers1

1

I can think of a couple of options that can be tried in this situation. To improve the concurrency under heavy load, we can test the below things.

  1. Use optimistic locking instead of pessimistic locking. Then either retry the failed transactions or ask the end user to retry. Reference: https://vladmihalcea.com/optimistic-locking-version-property-jpa-hibernate/
  2. Use Akka. Reference: https://akka.io/
  3. Use JCTools: MPSC. Reference: https://github.com/JCTools/JCTools
dassum
  • 4,727
  • 2
  • 25
  • 38