The way I think about scale is: 1) Know your bottlenecks and write them down. This is where you will look first if you have problems. 2) Know how you will thr

The way I think about scale is: 1) Know your bottlenecks and write them down. This is where you will look first if you have problems. 2) Know how you will throw hardware at it or change configurations if you find yourself with sudden growth you didn't expect. You need to create a buffer so you have the time to solve real code issues. Write it down. 3) Whenever you make an architectural choice, make sure there isn't one that's equivalent in engineer time that will be easier to extend later. Otherwise, just do whatever helps you learn about the product the quickest.