Ideal way to store product information in shopping cart in asp.net

Question

I am creating an ecommerce application, wherein i have a shopping cart.

My current structure is, whenever user saves the product, i put the product in the datatable and datatable to the session, so until session is not timed out, user can have the list they have saved.

I have however increased the session timeout to 600mins(10Hours), but my concern is, is this is best approach for storing shopping cart information, because if there are say for example 1000 Users accessing the site simultaneously, there will be 1000 session object created on the server, won't it deteriorate the performance of my website.

I cannot store it in database because if the user is anonymous i don't have the unique thing about the user, that way, if 1000 users are accessing the site, all products will get merge, i won't be able to fetch the product saved by the current user.

Is there any other better approach for this problem.

Answer 1

You shouldn't implement like this. Sessions of 10 hours are very long, if you have 1000 users on your website your server is going to suffer and will create some performance issues.

On our ecommerce websites we create a cookie for anonymous users. After doing this you have two solutions:

1. Store the entire basket in the cookie (basically list of product ID + quantity, more depending on your needs/strategy) or other techniques (e.g. localStorage).
2. Store a unique ID in the cookie and store the basket in the database (temporary table) with the unique cookie ID as identifier. Once the user log into the system you move those data to the user basket table.

You can easily change the expiration time of cookies (or remove it) without impacting the overall performance of your server. For IDs you can use Guid.NewGuid().

UPDATE:

More details about my second solution - scenario:

1. User visit website
2. You create a cookie with no expiration date: cartId with value Guid.NewGuid() (name and value are up to you).
3. User click on "Buy"
4. Get the cookie server-side and add the cartId,product/quantity to the "AnonymousBasket" table
5. Imagine the user leaves the website and come back a month later the cookie will be still here
6. If the anonymous user go to his basket you are able to get his products and quantities based on the value of the cookie.
7. If the user log on you remove the cookie and move data from the table "AnonymousBasket" to "Basket"
8. Now your logged in user can process to the checkout

With this solution everything is persisted in the database and doesn't require sessions. You can change the expiration of your cookies like you do for sessions, alternatively you can cleanup the temporary table without any risk or create statistics on anonymous users (why they didn't proceed to checkout, how many items in average, which item, ...).

Answer 2

@glautrou's answer is pretty adequate, and I don't support doing this by session either.

In addition to @glautrou's answer, I will explain how you can work on a single table without creating a different one.

Process steps:

1. User visits your site
2. Adds the product to the cart without logging into the site
3. When adding the product to the cart, you create a cart cookie for the user. You may not have a time limit for this cookie or you may set a 1-3-6 month limit. (note that if the user deletes their cookies, there's not much point in keeping the cookies that long.)
4. With this cart cookie, you save the product information in the Shopping Cart table (via ProductId). (ProductId, UserCookieCartCode, Quantity etc.)
5. As long as the user does not delete the cookie or the cookie expires, the user will see the products added to the basket before each visit to the site.*

*Of course, these products may be out of sale or the price may change. You can also do such checks.

Now let me explain them with some practice:

If the visitor is adding items to the cart without being a member, you create a cart cookie and add this value to the Shopping Cart table, for example in the VisitorCookieId field.

If the visitor decides to log in, you match the logged in userID with the VisitorCookieID and update the UserID field. The same will apply if one wishes to register a new one. This is an important criterion in terms of user experience.

Thus, you can manage the information of your logged in/non-member visitors from the same table.

An example of the Database Structure is as follows (exemplified for SQL Server):

Here you can only create a ShoppingCart table and keep information such as UserId, VisitorCookieId, ProductId, Quantity in a single table. However, this is not the right approach "in my opinion" because if the user converts this cart to an order, you have to take extra action as there will be more than one order line for the same user. In this structure, you trade on a single order information.

Maybe you can add an OrderId field in the ShoppingCart table and bind them when the cart is ordered. Of course, this will be valid unless you permanently delete the cart information that turns into an order.

Here are some important things; As I mentioned above, the user may delete the cookie, may not come to the site again, or may not purchase the products he has added to his cart. This is very important data for the user experience report for you.

E.g;

• If the visitor has added the product to the cart without logging in, the cookie ID is added to the VisitorCookieId field. Here you can analyze non-registered/not logged in visitors.
• If the visitor adds a product to the cart and then logs in, you will also update the UserId field that matches this cookie ID, as I explained in the top line. Thus, you can analyze the members who trade without logging in. The situation is the same for new registrations, in this case, you can look at the date of adding to the cart and the date of membership.
• You can examine those whose VisitorCookieId field is empty and UserId field is full, as those who log in and take action. Of course, there is another analysis opportunity here. Do these members have any other orders with the VisitorCookieId field filled?

These examples can be multiplied. In summary, using Cookie instead of Session is beneficial in terms of db and application performance. Also, trading with Session will not always provide the same efficiency, even if you set the duration of your data, it may be lost before that time.

There may also be problems with cookies; The user can delete cookies or not allow cookies. In this case, we will respect the user's choice and make it clear to they that it will not get good performance from the site if they does not use cookies.

As with general standards, it is important to decide which approach is best suited for your structure. Instead of general standards, the solution you find suitable for yourself may be better. Here I have made a suggestion combining the general standards with the solution that suits me, I hope it will be useful for newbies to this page.

** If you want to periodically delete this data, move it to a different table or report it, you create a scheduled task structure for them. Quartz.Net or Hangfire will be useful for these.