Let's discuss this in a bit proper detail with the application of performance, security and regulations. You can store anything that is publicly available on your website, and does not contain any personal or identifying information in a cookie. The reason for this is, that a user might be accessing your website from a public machine or PC and that data might be tracked or stored. Next, for a session you can use this storage to store any information that might identify (because, hey, that is what a session is about, right?) the user and help your website perform an operation quickly—without having to query the database again just to find out their user id, or email address. Do remember that on most frameworks (if not all), session data is sent to the client too. Now as per regulations, make sure you are requesting permissions from the users to store the cookies on their machines—European regulations require you do that, and then there is GDPR, and etc. etc. Now as for the database part, this space is expensive and filling it with the content that does not help you in anyway—let us for a moment ignore the analytics, user studies, machine learning for recommender systems, etc.—and they will only take away the space that you should pay for the content that helps you generate some business profits. What I would recommend here is, store the cart information in the cookies, just reference the URLs of the items they want to purchase. This way, the cart information will be stored locally. This will decrease the overall load on your web servers, and will not cause extra charges in the database storage as well since your users will be storing their interests locally and won't add a cart option in database, and forget it leaving there forever. One tip I can provide here is to use localStorage APIs, instead of cookies, because cookies also have a round trip from and back to server, adding an overhead on the HTTP request. [Window.localStorage - Web APIs | MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) In this approach, of course you will end up showing what John wanted to purchase to Johanna as well, and that can be fixed by storing the session id(! Remember, store only the session id not the user id and then verify that the sessions are same for the user—which can be done by some backend algorithm to check if user ids of the sessions are the same :laugh:)
The shit I complain abou