Speed and scalability are two sides of the same coin. Faster processing ensures more requests are processed for a given period. But then there are physical limits to speed of a single instance and that is where scalability comes in. Building a system using modular, decoupled and stateless services ensures that bottlenecked services can be scaled to maintain or increase throughput. Granularity of these services need to be carefully chosen as finer granularity may reduce performance due to message serialisation and deserialisation. Furthermore, processing efficiency of these individual services is important as scaling inefficient services is costly. So, start with modularising and decoupling and then optimise these services for economy.

I think, here's what most people overlook: scalability should take precedence. In my experience, I have learned that an application optimized only for performance can falter under unexpected loads. Prioritizing scalability ensures your system can grow seamlessly with user demand. Instead of squeezing out every millisecond upfront, design an architecture that can expand horizontally or vertically as needed. Remember, a blazing-fast app that can not handle growth won't serve users in the long run. By putting scalability first, you lay the groundwork for sustainable performance and success.

To ensure scalability takes precedence over performance in a high-traffic application, think of your system as a stretchable rubber band rather than a speedy race car. While the race car zooms ahead, it can only carry so many passengers before it crashes; in contrast, the rubber band can expand to accommodate a growing crowd without snapping. This means designing your application with horizontal scaling in mind, allowing it to add more servers as traffic surges, much like adding more lanes to a highway during rush hour. Implementing microservices architecture can further enhance this flexibility, enabling different components to scale independently based on demand.

- Build some forecasts of throughput (traffic) - Understand what acceptable latency (response times) are for relevant user actions or business events - Break the system down into separate components/systems with clear interfaces Now, for each component - Work out what your scalability options are. Can it scale horizontally? Vertically? - Work out how soon it might reach its throughput or latency limits Use this information to decide where to invest your effort now and where you don't need to lose sleep over until later. The clean interfaces between different parts of the system make them behave like black boxes, as long as the interfaces stay the same they can be re-written easily.