Scaling Out re-design approach?

Question

My current web app provides a service to clients on a single site. It is NOT eBay, but I will explain using eBay as an analagous service we can all understand.

A client sets up a page, and other peer users can go to the page, do business, and the site charges for the service, the trades done.

Currently my site is monolithic so does not scale well. All users sit on the same site, and run on the same database, pages hosted in site.

With a redesign for AspNetCore on the cards, I would like to design in some scalability.
I would like to make the selling page in the above example a "site", ie a distinct web application, and fire up such a web application on demand.

Identity Authentication and Authorization will be handled by a stand alone singleton server, issuing tokens (if you like, authenticating against Facebook instead, etc).

A selling client approaches a minimalist central site to set up a selling "page". The selling page, and associated database and app mechanics pertaining to that page are all hosted in a single web-app, which is run on an an elastic resource host (virtual server or docker instance). The page lifetime would be multiple days. The central site runs continuously.

AspNetCore is attractive because the "selling page" site becomes an exe that is spun up on demand.

I am not sure how to make the central site spawn the selling page site on demand. Ideally I would like to avoid marrying a service supplier like AWS or Azure. Would Docker make the app service agnostic? Am I even barking up the right tree?

Answer 1

It is not clear to me that putting each seller site on its own application is beneficial. In fact, I could see it causing major performance degradation, in addition to unneeded technical complexity. I surmise you want to go with this approach because it seems cool, not because it has any tangible performance benefit.

Now, giving each seller its own DB is likely more beneficial, and easier to implement. The same way you have a repository method to insert a new row, you can have a method that inserts new tables. You don't need to design a convoluted meta-base or anything; sqlserver, ect, already have all the functionality you need built in. Seller specific DBs afford many performance advantages, such as avoiding unneeded locking during transactions, limiting the number of rows in a single table, and allowing scaling out without costly synchronization concerns.

Your focus should be the following: 1. minimizing cross request app-server memory access. 2. Isolating distinct functionality.

If you do not store things in session memory, it becomes very easy to spin up an additional web-server when demand dictates.

The classic way to isolate distinct functionality is to have the webapp, batch jobs, and database running on different servers. More advanced options can include having a specific cert server to take care of encryption, large file/image servers for static content, or a sales-transaction server. Looking at the specifics of your application, you may find even more isolatable functionality.

Answer 2

There are two ways of scaling: scaling up (vertical) and scaling out (horizontal).

Scaling up involves getting a single machine to do more, e.g. by adding CPUs, or by architecting your software so that it only performs a very narrow range of functions.

Scaling out involves architecting your software so that it can be supported by multiple machines ("nodes") without any adverse impact on logic. For example, a series of 10 web servers running identical code may be used with a load balancer to increase your capacity tenfold.

Scaling out is generally superior because you can keep scaling forever (you can add 10, 20, 100 nodes). Vertical scaling generally is going to have a hard limit.

So in this spirit, I would suggest you abandon the idea of "one seller, one application" and instead put all sellers on one application, but design the application so that it can be run in a load-balanced environment on a number of machines. The basic steps for this are:

1. Eliminate or control dependence on process-specific state (e.g. session variables held in-proc). You can do this by making your application stateless, offloading state to a a separate state server (e.g. AppFabric), or (in a pinch) by enforcing client stickiness.

2. Database scaling tends to be the most difficult part due to the requirement for ACID. To get your web apps to scale out, you will want to reduce database load as much as possible.

3. Develop for multitenancy so that sellers can safely coexist on the same application while retaining their logical independence.