Think about what you are building and start illustrating it as arrows and boxes on paper. Then, walk through a few simple use-cases, amplify them and try to identify points of failures and bottlenecks.
For instance, if you built a web service which exposes an endpoint to upload an image and then processes that image to generate thumbnails for hundreds of social media formats, what could go wrong?
It is possible that the server blocks all incoming requests while it is processing an image that was previously uploaded. What can you do about that? Do you add a second service? Or, do you extract the functionality to upload images and generate thumbnails into a separate service? Furthermore, could a third-party service be utilized instead of implementing this feature yourself. What are the associated risks and limitations with all the above approaches? Are there any security or resource constraints? Are there budget limitations? A lot of factors are involved while deciding when to scale services.
There are so many questions that you need to ask yourself. So, what do you do? You read/learn what is involved in making highly-scalable services and you apply the best possible design patterns to architect your single service. Make it modular so that you can always move things around with the least amount of disruption. Rely heavily on test automation.
What happens if 100 people use this service vs. 1,000 vs. 1,000,000? When you have an ideal solution, these growing numbers won't bother you. Would a reverse-proxy load balancer be the answer here? Perhaps. Often you can take multiple approaches to scale.
As a general rule, write the most efficient code you can in the shortest amount of time. Don't spend too much time optimizing it until you need to. Focus on high-level architecture as splitting things is always difficult to do later on. However, you want to start with a monolith for a v1 product and then think about distributed-systems or microservices. You will need to run tests to measure service performance. Your decisions should be data-driven.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Think about what you are building and start illustrating it as arrows and boxes on paper. Then, walk through a few simple use-cases, amplify them and try to identify points of failures and bottlenecks.
For instance, if you built a web service which exposes an endpoint to upload an image and then processes that image to generate thumbnails for hundreds of social media formats, what could go wrong?
It is possible that the server blocks all incoming requests while it is processing an image that was previously uploaded. What can you do about that? Do you add a second service? Or, do you extract the functionality to upload images and generate thumbnails into a separate service? Furthermore, could a third-party service be utilized instead of implementing this feature yourself. What are the associated risks and limitations with all the above approaches? Are there any security or resource constraints? Are there budget limitations? A lot of factors are involved while deciding when to scale services.
There are so many questions that you need to ask yourself. So, what do you do? You read/learn what is involved in making highly-scalable services and you apply the best possible design patterns to architect your single service. Make it modular so that you can always move things around with the least amount of disruption. Rely heavily on test automation.
What happens if 100 people use this service vs. 1,000 vs. 1,000,000? When you have an ideal solution, these growing numbers won't bother you. Would a reverse-proxy load balancer be the answer here? Perhaps. Often you can take multiple approaches to scale.
As a general rule, write the most efficient code you can in the shortest amount of time. Don't spend too much time optimizing it until you need to. Focus on high-level architecture as splitting things is always difficult to do later on. However, you want to start with a monolith for a v1 product and then think about distributed-systems or microservices. You will need to run tests to measure service performance. Your decisions should be data-driven.