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.

Solution 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, ...).

Solution 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.

Comments

[Abbas]

Hi @glautrou, that could be the good solution, but what if the cookie is disabled on the client end.

[glautrou]

If cookies are disabled sessions are likely to be disabled as well. If you bother about disabled JavaScript you can pass the "Basket ID" in all your URLs. This is not very nice, but you don't have many choices in that case.

[Abbas]

I guess cookies are store on the client side and sessions on the server, so user cannot disable the session from browser's end, as it resides on the server.

[glautrou]

You can also use for example localStorage to avoid cookies but you will have some other problems like compatibility or private browsing.

[Abbas]

Isn't there any full-proof method of doing this.

[glautrou]

Yes sessions are on the server, but there is a cookie stored client-side. Otherwise how can the server know whose session is it?

[Abbas]

Hi @glautrou, can you please elaborate your 2nd solution, you provided in the answer above, "Storing unique id in cookie..."

[glautrou]

Please look at my updated answer. Hope that answer to your question.

[Lucky Pierre]

I like this answer by glautrou. That's pretty much how we do it at my company for a number of high profile clients. You'll run into a lot of performance issues as your site grows if you're using session. Cookies I think are the way to go. If a user does not allow cookies, then you should display a message saying cookies must be enabled. There's really no approach that will satisfy 100% of all internet users.

[Abbas]

Hi @glautrou, sorry for asking it so late, according to you i should store the GUID in cookie and reference that GUID in database which contains all the items. Now user clears cookie or deletes temporary files, then i won't be able to retrieve the items of that anonymous user, the next time he visits my site. Also if this happens often, i will end up have millions of useless records in my database.

[glautrou]

In fact there are several strategies depending on your needs. You don't have to store temporary data for years (or can clear after 6 months). If you don't want to store in your database you can store the entire cart in a cookie (eg. ProductID + Quantity). I think the user is aware that if he clears his cookies he will lost some stuff on some websites, like "remember be" feature for example. If you still want no to use a cookie you can retrieve the basket by using his IP address (bad solution) or asking him to create an account to store a wish list (not attractive solution for new customers)

[Abbas]

If there are 2 anonymous users visit on single machine, and if one user has added some items in cart, and leaves website and another user visits website, in that case he will also see the same products in the cart. is there anything we can handle in that case.

[glautrou]

Use a cookie for anonymous users