Design for Failure: Processing Payments with a Background Worker
petekeen.net
petekeen.net
If you do something like this you need to make sure to verify that the user actually created the transaction. Blindly loading it by id and returning it back would let any user check on any transaction. Plus it's particularly easy if the ids are sequence numbers.
In my case I use pcntl_fork() in PHP to split off a job to communicate with the payment gateway.
The parent process returns a hash to the client.
The client then polls with this hash. The child process communicating with the bank will put the bank's response onto a beanstalkd tube named using this hash.
EDIT: Also, is it really a good idea to poll every 500ms? Why not use long polling?
RE EDIT: From the article: "Typically, this completes almost immediately.". A 500ms poll isn't really a problem when for most people it will return success on the first poll.
Also the 500ms poll looks like it is coming from the client - that definitely seems like a no-no. You'd hit the server 60 times over a 30 second back-end timeout.
The worst time to ratchet up load on your server is when your back-end is having issues.
SuckerPunch won't actually retry the job. In this simple example the backgrounding mechanism is mostly for insulating you from the browser's timeout.
RE the poll: I tend to do doubling polls for stuff like this (500ms, 1s, 2s, 4s, 8s, etc), but in this case I don't think it matters, since all the server does is one database lookup and render as json.
Side note to OP: It seems like a bad idea to use the auto-incremented id as a key for polling, since it would allow an attacker to get full details of all transactions.