This question concerns a design decision. I am currently working on a web project in which there will be 40K users, and in a couple of months 50M users (although not simultaneous users) are expected to grow. I would like to have an architecture that can be easily scaled without much effort.
To explain, I would like to use a trivial scenario. Assume that user objects and services, such as CreateUser, AuthenticateUser, etc., are a simple method call for page controllers. But as soon as traffic growth increases, for example, authentication of the user (or such services associated with user objects) must be transferred to another internal server to distribute the load. But at the same time, using RPC calls over the network when the user counts 40K will become redundant.
My suggestion was to use IPC natively, and when we need to scale, we can mutually switch to TCP based RPC calls so that it can scale easily. For example, I mean System.IO.Pipes.NamedPipeStreamServerto start and move on to TcpListenerlater.
If we have the right design that can encapsulate the above mentioned approach, it would be easy for us to scale services on multiple network servers, but at the same time avoid network calls when the number of users is small.
Is this a better approach? Any suggestions would be great.
Note. Scaling the database is, of course, the second phase of optimization, so we have already made an architectural project for easy data separation while increasing traffic. The main bottleneck will be the application server for a period of time.
source
share