Solution
1 user; We are against any premature system scaling because it unnecessarily complicates the development process & distracts from the implementation of the major features. In the meantime we always laid the foundation for further optimization We isolate each application, API & DB using Docker containers Docker automates the repetitive tasks of setting up and configuring development environment & guarantees that software will always run the same. We use New Relic for deep performance analytics in real-time. Under prototyping, we use single AWS instance with flexible approach to choose the appropriate resources for the application
1 000 users; With great activity comes great server load. To prevent loss of performance several recommendations should be taken into account. Amazon Elastic Load Balancing allows quick & easy vertical scaling of the system. Frequently accessed static content should be served from CDNs They allow users to download content from local third party servers instead of our distant servers. This improves performance and also reduces the need to build and maintain own global network
100 000 users; Beyond the MVP stage increased traffic brings new technical challenges. With growing data arises a need to overthink its storage. Frequent high loading requests should be cached with Memcached Low latency data should be moved to the separate cloud storage Elastic Stack solutions can help too. System updates cost more on later stages. Splitting monolith systems into micro-services allow to decrease that cost. Each service can be developed and deployed independently. They improve fault detection, isolation, and recovery & eliminate any long-term commitment to a technology stack
Premature scaling can lead to unnecessary complications. Belated optimization can cost more. Project architecture design is the long-term process, which requires constant monitoring & adoption of carefully considered and weighed decisions