Where should you store your cart?

When building an e-commerce site, the question of cart persistence will usually rear its head. There are many options for where to store the users shopping cart information, each with pros and cons. Consider what makes up your cart logic and what solution is most suitable to you.

Session State

When a user connects to your website, whether they know it or not, they are assigned a unique session by the web server. This is used so that the server can tie user requests from the front end website to the back end and make sure that each user receives the item they requested. To store a cart in session in the .NET framework is quite simple.

Assuming you have a cart model object that stores basic cart information – Product_ID, Quantity – as long as that model is decorated with the [Serializable] attribute then it can be stored in session by simply assigning an instance of the model to a session object with an arbitrary name i.e.   Session[“UserCart”] = cartModel.

To retrieve the user cart simply cast the session back to a new instance of the model class:  var newCart = (CartModel)Session[“UserCart”].

Session is a quick and easy method to store unsecured information as it disposes of itself and becomes inaccessible to the user once they have closed their browser. This itself can be considered a con, which is when you might look at other options.


A cookie is very similar to a session (and its implementation in .NET almost identical) except that it is stored entirely on the client side. This means that the cart information can be manipulated by a user, so you need to be smart about what you store. Cookies are also very small (4Kb) so storing all cart information may not be achievable. Cookie storage is best for simple objects such as name, email address etc. and not complex types like shopping carts.

Web Storage

Relatively new and not supported by Internet Explorer 7 and below is Web Storage. It behave very similar to a cookie except that up to 5mb of data can be stored and is considered more secure. Implementation techniques are very similar to session and cookie and web storage is available in both cookie-like “localStorage” objects and session-like “sessionStorage” objects – the former being accessible after the user restarts their browser, the latter not.


My favourite approach is database, which could be achieved in multiple fashions itself.

If your website is anonymous (i.e. no user accounts) then you could establish a cart session in your database and assign the identifier to a cookie. Each time the user requires a cart, look for this cookie and the ID contained within, then retrieve the cart from the database. This also gives you the advantage of being able to track what is in user’s carts at any point in time – good for your analytics!

If your website employs user accounts (i.e. a user must log in before they can add items to cart) then no cookie is required – simply relate your cart database table information to the user database table. With this method you would also be able to see what is in a user carts at any time and additionally relate it back to a specific user (you might want to consider your Privacy Policy in this instance!)


Considerations for all methods – particularly those that survive browser relaunch – is keeping your cart up to date with what is available in your database. If a user comes back to your site a week later, the product they added to their cart previously may now be out of stock. You should therefore always, when loading the users cart for the first time per session, evaluate that all items within are still valid and react accordingly.