I'm building a ecommerce application with MySQL, but I'm having a hard time coming up with a solution that prevents the following race condition:
Two users checkout at the same time with the same item in their cart. The store only has one item available for sale. One user should be able to purchase the last item, and the other user should see an error message because the item is out of stock.
I'm using an item counter to keep track of the number of items in inventory, so I figure I would just decrement the item after processing the user's credit card.
I know about the SELECT...UPDATE query in MySQL, but I'd like to stay away from locking rows or tables - unless that's really the best way for an ecommerce app to solve this problem.
I'm also interested in hearing other solutions other than checking/decrementing an item counter.
Why are worried about locking. It wont hurt you till you have 100s of simultaneous customers at a time and database engines like innodb are made to handle those things. You wont be able to get way from some kind of atomicity and workaround.
You need to keep application level transaction management.
checkout
reserver_the_items_in_cart
if(reservation_succesfull){
get_the_payments_done_via_payment_gatway
if(payment_successful) {
update_the_reserverd_to to sold_status
}else{
make_reserved_item_to_available.
}
}else{
show_error_that_item_not_available.
}
Other best way to handle this is never allow "show_error_that_item_not_available" to happen. Replenish inventory on time when it started running out.
The way I am going about this is
1. check availability for X books
2. if there are X books, place the actual order
3. check availability again if availability is ok, then everything is ok... if availability is off, I reverse the order and notify customer.
Related
I am working on an Express-based (Nodejs) API that uses MySQL for data persistence. I have tried to follow the CLEAN ARCHITECTURE proposed by Sir R.C. Martin.
Long story short:-
There are some crop vendors and some users. A user can request an order of some crops with a defined quantity from a vendor. This puts the order in PENDING state. Then the vendor will confirm the orders he/she gets from the user.
Domain/Entity -> CROP, Use-case -> add, remove, edit, find, updateQty
Domain/Entity -> ORDER, Use-case -> request, confirm, cancel
I have to implement a confirm order functionality
I have an already recorded order with ordered item list in my DB (order in the pending state)
Now on confirming order action I need to subtract each item quantity from respective crop present in the DB record, with a check that no value turns negative (i.e. no ordered qty is more than present qty)
If it is done for all the items under a "transaction cover" then I have to commit the transaction
Else revert back to the previous state (i.e rollback)
I know how to run Mysql specific transactions using "Sequelize", but with a lot of coupling and poor source code architecture. (If I do it that way, then DB won't be like plugin anymore)
I am not able to understand how to do this while maintaining the architecture and at what layer to implement this transaction thing, use-case/data-access, or what?
Thanks in advance
I recommend keeping the transaction in the "adapters layer" by using "unit of work" pattern. This way the database remains a plug-in to the business logic.
Okay, my partners and myself created these a while ago. We are going to be transferring this into SQL through Visual Basic soon, but I want to make sure everything is ready to go. Two major complaints that we were not able to fix was...
"By having Transaction and Product directly connected you are unable to allow multiple products on the same order (customer can't order both a latte and cappuccino on the same order)."
"Membership table: Not sure what the data in DiscountTypeTotal means - do you have multiple pieces of data in the same field? (then your table isn't on 1NF).
It looks like you need to allow each member to have multiple discounts - so you need another table to capture that."
How do we effectively correct these? How else would we connect Transaction with Products? I understand that the customer can only purchase one item per transactions, so would we have products and another table for multiple items? Allowing multiple customers to have discounts, I am lost. Any help would be appreciated.
I'm trying to draw a database design of an ecommerce, and fulfilment of order platform. The company currently has a distribution centre for fulfilling the orders. But they want to extend this to use its stores for a part of the fulfilment process. I have designed a database of "internet sales" and "store sales", but I am stuck on the fulfilment of the internet order, and I wonder if any of you can help me with this.
Scenario : When the customer places in an order, and the distribution centre doesn't have a stock of an item to ship to the customers, the item needs to be taken from one of the stores. This item is then sent to the customer.
But the problem is that I can't just take an item from a store, and then send it to the customers, because the item hasn't been sold in the store, its (store) stock database isn't going to be updated. If I put the item through the cash machine, the item is removed from the stock table, but there are two transactions for the same item - one transaction from the internet, and the other from the store.
I guess my question is, how do I go about processing internet orders, and avoid having two transactions on the same item?
Any helpful pointers on this issue is greatly appreciated.
Update : Here's what I have done so far after advice from Jo Douglass,
Database Design Here
Sorry, I can't post images, because I don't have enough points. And please note that the above database design isn't complete
It sounds like you have a Transaction entity, and you have or are planning on having some logic which ensures that when one of these is created for an Item, your system knows to deplete the stock level for the relevant location (either a store of the distribution centre).
You could use an entity which shows an Item being transferred from one location (a store) to another (a distribution centre), and then create some logic which works very similarly to your existing logic - depleting the stock level in the starting location, and increasing the stock level in your destination location. Then when you carry out the last part of the process (sending the item to the customer), you'll have a Transaction showing that and depleting the distribution centre's stock level. Depending on the rest of your model, you might carry this out via a change to the Transaction entity, or by creating a new entity altogether.
Alternatively, if that doesn't really model what's happening in the business very well, then maybe you just need to modify your logic (and possibly your model - hard to tell without seeing your existing model). Rather than only being able to create store transactions via use of the cash register, perhaps you simply need to be able to create a store transaction that's been kicked off via the Internet.
One idea is to go ahead and treat the item as sold from the store (through an online transaction) and credit the store's account with the sale price. The distributor has probably already received the wholesale price from the store so it's happy, the store gets credit for the sale (with at least some part of the shipping charges) so it's happy, and you don't have to create new transaction codes or any other modification to the existing database.
I am creating a new DB in MySQL for an application and wondered if anyone could provide some advice on the following set up. I'll try and simplify things as best as I can.
This DB is designed to store alerts which are related to specific items created by a user. In turn there is the need to store notes related to the items and/or alerts. At first I considered the following structure...
USERS table - to store basic app user info (e.g. user_id. name, email) - this is the only bit I'm fairly certain does not need to be changed
ITEMS table: contains info on particular item (4 fields or so). Contains user_id to indicate which user created/owns this item
ALERTS table: contains info on the alert, item_id to indicate which item the alert is related to, contains user_id to indicate which user created alert
NOTES table: contains note info, user_id of note owner, item_id if associated with an item, alert_id if associated with alert
Relationships:
An item does not always have an an alert associated with it
An item or alert does not always have a note associated with it
An alert is always associated with an item. More than one alert can be associated with the same item.
A note is always associated with an item or alert. More than one note can be associated with the same item or alert.
Once first created item info is unlikely to be updated by a user.
For arguments sake let's say that each user will create an average of 10 items, each item will have an average of 2 alerts associated with it. There will be an average of 2 notes per item/alert.
Very common queries that will be run:
1) Return all items created by a particular user with any associated alerts and notes. Given a user_id this query would span 3 tables
2) Checking each day for alerts that need to be sent to a user's email address. WHERE alert date==today, return user's email address, item name and any associated notes. This would require a query spanning 4 tables which is why I'm wondering if I need to take a different approach...
Option 1) one table to cover items, alerts and notes. user_id owner for each row. Every time you add a note to an item or alert you are repeating the alert and/or item info. Seems a bit wasteful but item and alert info won't be large.
Option 2) I don't foresee the need to query notes (famous last words?) so how about serializing note data so multiple notes are stored in one row in either the item or alert table (or just a combined alert/item table)
Option 3) Anything else you can think of? I'm asking this question as each option I've considered doesn't feel quite right.
I appreciate this is currently a small project and so performance shouldn't be of great concern and I should just go with the 4 tables. It's more that my common queries will end up being relatively complex that makes me think I need to re-evaluate the structure.
I would say that the common wisdom is to normalize to start and denormalize only when performance data suggest that it's necessary.
Make sure that your tables are indexed properly, with foreign key relationships for JOINs.
If you think you'll end up with a lot of data, this might be a good time to think about a partitioning strategy. Partitioning your fast-growing tables by time would be a good first step.
Four tables is not complex. I commonly write report queries that hit 15 or more tables in a database structure that has hundreds of tables (most with millions of records) and I wouldn't even say our dbs are anything more than medium sized (a typical db in our system might have around 200 gigs of data, so not large at all as databases go). Because they are properly indexed, they still run fast unless I am doing very complex calculations. Normalize, don't even consider denormalizing until you are an experienced database designer who knows better than to worry about the number of tables.
What is the general pattern or approach to managing transactions in a web-based e-commerce system? How do you handle the situation where more than one user tries to buy the last item, for example?
To prevent two users from purchasing the same stock item of which there is only 1 unit in stock, you need to check that each item in a user's cart has stock available right before you create an order and decrement stock for that item.
This operation will have to be atomic and only one order can be processed at any given time (read: database transaction), which should not be a problem if you are using a central database for stock management.
If stock has run out by the time a client checks out, you should remove the item from the client's cart and redirect them to their shopping cart, informing them of the situation.
Of course, this situation only occurs when two users both add the same stock item to their cart of which only one unit is in stock and one of them checks out. First come, first served. You should generally not allow clients to add products to their cart if no stock is available at that moment, unless you can order new stock within a reasonable amount of time, but in that case, the whole point is moot.
You can take a preemptive approach by checking that stock is available the moment a client initiates checkout and take the same route as above. However, that would depend on the nature of your product and the volume of transactions vs cancelled orders. If it is likely that another order for the same item was cancelled in the meantime and stock becomes available by the time a client checks out, then you don't want to lose a sale by telling the client that no stock is available. Better to let the order fail at the moment stock is not available and inform the client of the situation, which is rare after all.
Why not take the order and then get that item for the customer, perhaps a bit later? You can win a repeat customer :)