title: Should I Use A Queueing System To Handle Payments?
body: <p>I'm using <a href="https://www.slimframework.com" rel="nofollow noreferrer">Slim</a> in conjunction with <a href="https://stripe.com/docs/api/php" rel="nofollow noreferrer">Stripe's PHP Library</a> to process payments in my application. </p>
  
  <p>All is well, however up until recently, I have discovered an alarming fault in my system that I believe may be a much larger issue than I probably think. In my logic, at three separate checkpoints of the payment process I inspect the inventory in my (MySQL) database to ensure a user isn't purchasing more products than is available. </p>
  
  <p>However, when multiple users make a request within approximately <em>500ms</em> of each other, the payment system seems to process these requests all at once, resulting in a slew of issues ranging from incorrect and unbalanced inventory, to false user confirmation of successful payments.</p>
  
  <p>Through some due diligence, I have narrowed a solution down to two options (although I may be selling myself short):</p>
  
  <p>1) Use a <a href="https://www.codementor.io/smorhaim/creating-simple-powerful-queue-system-beanstalkd-microservices-du107kllb" rel="nofollow noreferrer">Queueing System</a> that, from my understanding, will queue these request and process them one at a time, creating a sort've first-come, first-serve basis.</p>
  
  <p>2) Attach some middleware on to each request that will act as a queue and attempt to process each request synchronously (although this may be similar to what i already have in place)</p>
  
  <p>Now with that said, any suggestions/opinions on these options? and obviously feel free to totally scrap my idealogy and point me in a different direction.</p>