How to implement a Web-Shop with a Shared Nothing architecture

Some people argue that it is possible and even necessary to implement every webapp with the Shared Nothing architecture. How is it possible to implement a webshop with a shopping cart using this architectural style?

Normally a webshop can be implemented using sessions. In this case I'd have to implement it in another way, so that no information about the cart is stored on t开发者_如何学Pythonhe server. But then it would be necessary to include the cart contents into hidden fields, so that they get passed to the server along every single request. Is that the solution for a webshop using Shared Nothing architecture?

Do you have any ideas on how to achieve the shared nothing architecture for webapps?

Although I have never explicitly gone out to build a Shared Nothing (SN) based system, I would suggest that anyone who says it's necessary to architect WebApps using "pure" SN are:

• Have a budget so massive they can utilize a million clusters for every tier.
• Are academics who never actually implement anything.

If you have a cluster of web-servers, and are load-balancing traffic in a way which means you can't guarantee that the same web-server will handle every call for a given session - then yes, the tenets of SN apply: you can't afford to introduce server affinity.

But to stretch this for "every" web-app is simply absurd.

SN, like all other architectures, are like tools - they are solutions to problems; the problem defines the solution - not the other way around.

As for my experience with webshops, shared-nothing architecture is better than session-based. I've so many times been extremally annoyed with having my shopping card dissapeared because of session expire! AJAX or not, webapp should at least store user's selection in cookies, or, when available, HTML5 Storage and other wonderfull mechanisms.

However, HTTP Session based apps have also their pluses, espetially when caching on server side the resources for users, which acquirantion is costful - typical for heavy-load heavy-business-logic transaction systems. In many cases mixed solutions would be the best choice.

So my answer is - it depends. You should write requirements and choose what is the best, not carying what is the name of pattern or architecture you're applying :)

You could use a distributed cache (e.g. memcached) to store session data on the server side.

Services provided by leading cloud providers may give you idea about how to achieve SN in tree-tier application. Using load balancers with different policies help you to move shared resources to their own servers, so it makes your application servers available to network. But RDBMS is always bottleneck against to SN.

To offload session handling load from database, in memory cache comes for the help, since the data is in the RAM and resiliency managed by Redis(e.g.) session data access becomes faster. File storage for app and db servers is addressed by NAS and servers can be mounted to NAS, it helps to mitigate HDD, SSD failures and provides faster/resilient IO. Search activities are also the burden on RDBMS. ElasticSearch can offload search load from your DB. Another improvement that can be done is using an in-memory cache in front of your database for queries. If a record hasn’t changed since the last fetch, you can simply pull it from the cache, instead of DB.

Most of the time read queries are more than updates/inserts. In such case, if one DB is not able to handle the read load then you can create multiple read replicas of your DB.

If load reaches a stage where even using the read replicas doesn’t work, then the last option is to shard your database, so your business are going quite good and you will have resources to solve it when the time comes for sharding.