Designing for scalability isn't that hard, as long as you understand how big things scale and what their normal failure points are. The biggest problem seems t

Designing for scalability isn't that hard, as long as you understand how big things scale and what their normal failure points are. The biggest problem seems to be connections to the database. Front-end people use databases as a persistent store, and don't realize that databases have connection limits. Your front-end or middleware scales, but your backend won't. Your data store should be able to handle your connection load. That might mean pulling the database information and putting it into a cache (redis, memcached). You need to understand where the bottlenecks in your systems are/will be. Authentication is always a bottleneck; can your system handle 5 million attempts at authentication in a second? Probably not. You also need to understand your failure modes and how to handle them. In the above case, exponential backoff won't really work. If you can only authenticate 1000 users a second the other 4,999,000 users will be hitting your service at exactly the same time, every time. Randomly distributing them across the backoff interval is pointless. And even at your fastest throughput authenticating your users will take 5,000 seconds, or around 83 minutes. That probably won't work out. Assume you need to store tokens for all of the users, well, that means 1,000 writes to the DB a second. That probably will fail as well. Most of the time you'll be lucky to get a few thousand users. But at some level you should understand what you'll need to do if you get lucky and your utilization pops. The problem is that you do need to understand your end-to-end architecture to do this sort of analysis. And experience counts; if you're aware of what you need to do you can design things in such a way as to make scaling easier (ie: no major rewrite required).