I'm working on a small project on Google App Engine, trying to implement a site that allows participants to buy and sell fake goods, similarly to a stock market where the system will show real time-ish BID/ASK spreads.
As a quick example:
- A Seller places and order to sell 10 Boxes for 8.00 (Order 1)
- A Buyer places then an order to purchase 5 boxes for up to 9.00 (Order 2)
When the second order is placed, the system will need to do multiple tasks, all contingent on all of the tasks completing successfully.
- Take the funds (8.00 x 5) to pay for the boxes from the Buyer and give them to the Seller
- Take the boxes (5) from the Seller and give them to the Buyer
- Update the orders as complete (OID 2 ) or update as partially filled (OID 1) so that they cannot be double matched
- Take a fee from each of the participants and add it to a system account
If all that I needed was to move funds from one participant to another, I can do that safely even if the system were to fail in the middle. But to ensure that all of the tasks above complete correctly, and roll-back if any of them fail seems overly complex in App Engine.
Additionally, my "Order Book" and order matching engine are single threaded right now (using Mutexes for locking.) This seems to go against the whole point of using App Engine, but I'm not sure I see a way around it.
So (finally) - My questions are:
- Is there a best practice when using App Engine where there are multiple steps that all depend on every step completing correctly?
- Does anyone have any suggestions as how to either, allow the order book to be multi-threaded, or if it remains single threaded - is there a best practice to not have this core piece block the use of the site as it scales? I've thought about using tasks to queue the order adds/updates/cancels to keep the book separate from direct participant input.
Thank you, I look forward to your help!