How to think about scaling

Any software engineer will have to think about scalability at some point. As companies grow and have more transactions and users, that's when scaling issues start showing and really stop a business from growing further.
I have worked for big enterprise companies to startups, and learned how enterprise level companies focus on scaling in very early stages of their projects and features building, and where it sometimes is not necessarily a priority in startups. I was also part of a startup when things started to pick up and we got millions of transactions over course of an hour, and have observed us failing because we did not think about scalability soon enough.

In this article I will talk about what I learned and how I believe companies can think about scaling from early stages to have the potential of being enterprise level.

1. Choosing the right tech stack
   When it comes to tech stack, a lot of founders can be biased and go based off what is trendy or what they are mostly comfortable working with. This makes sense, but in addition to these factors you should also think about things like, how big is the community of the programming language? What is going to be the learning curve for new employees or how hard it is going to be to find experts in that language.
   For example, if you choose something like Clojure, it might be fast and efficient, but how many people really know and practice that language.
   Same goes for other tech stack technologies such as database. If you decide to go with a NoSQL, would you choose a popular one with a big online community, or one that not many people have experience in, and one where there are very specific potentially with some bugs and security breaches libraries to connect to your main system.
   Overall, choosing the right tech-stack is the most important and potentially one of the biggest tech debts you will face for growing your company!

2. Architecting your system
   Monolith or Microservices? It's crucial to know when it's time to switch from one to another. When your system becomes too risky to be deployed all at once to all clients. And we all want to be agile and have many deployments during one day.
   In addition to that, making sure that the core logic has enough test coverage is very important from very early stages of development. Not saying you have to necessarily practice TDD (Test Driven Development) to success, cause that can be exhausting and tedious on devs, but it's always important to have a test or two for what we consider a bad customer experience or a failure in a feature we are developing.

3. Database
   Database is probably one of the biggest bottlenecks to companies' scalability issues as they grow. Although there are solutions such as distributed and in memory caching that are made to workaround around these issues, they are not necessarily enough.
   I read in a book that accessing data from database should be always your last resort! When you cannot save something as a constant in your code, when you cannot cache it, or the TTL has reached; in other words, only call database when you really need the data. This is very important because I have seen so many times in codes where the data that we are retrieving from database are never used by their caller. Detecting these as the codebase gets more complex can be challenging. So it is always better to have these in mind ahead of time.

DBRI or Database Read Isolations is another solution where you split your APIs into categories where they only need to read data that are not necessarily that time sensitive (it is ok if they are not completely real-time), and where it is absolutely required for them to be real-time. In the former case, you can hook those endpoints to only connect to your secondary database clusters, and as they scale you can create more secondary db clusters.

Indexing frequently queried fields in your table is also very important and crucial.This can make a dramatic difference if an index was missing and later added, and as mentioned before, detecting these later as your system grows can take too much work.

Choosing the right data schema is also very important. Think about it like this; you can literally put everything in a huge table and only have one table in your company. why not? It is very important to know where to set the boundary. Where to think about domain driven design in your database design and

4. Fail when it is taking too long to fail
   Timeouts are very important on every level of your system, from API to database queries, to locks on resources, there could always be a deadlock in your system where resources are not freed up so having a deadline aka a circuit breaker pattern always helps to free up those resources for next upcoming requests. It's always better to fail for one customer than thousands

5. Observability
   Monitoring is always very important in scalability and success of a business. In a nutshell, it makes sure you catch issues before it is reported to your customer service or is reflected as a bad review on your app!

6. Load Testing

7. Pagination and Loading states (UI hacks)
   Sometimes it does not matter how much you optimize and cache, there are just too many requests and the page load is heavy. But does the UI really need to display that much of data in one page? Can we have a briefer model of our entity that is sent to the client side, and only when user clicks on it load the whole thing?

Can we only show a limited number of entities in a page and introduce "load more" and pagination in our application? These can save you a lot when it comes to practice

8. Rate limit your clients!