Users has to be the worst unit you can possibly use, there's just to much variance between projects. If it's 100k users for a timesheet app people use once a we

Users has to be the worst unit you can possibly use, there's just to much variance between projects. If it's 100k users for a timesheet app people use once a week you've got very different scalability requirements than a 100 user app that people constantly interact with day in day out. Even then there's big differences depending on the domain, 100k users inserting data into a single table looks very different to the same entering information across 30 tables. You can't just pretend there's magic numbers that apply to everyone. Many of those steps are reduce scalability if they're applied prematurely, splitting out the API and database layer at 1000 "users" is going to use more resources serializing things across the network than keeping it in process would. Same for seperating out the database, it's great if you need it but there's a cost if you don't. I worked on one system where we pulled out the API layer after realizing that this was where ~50% of our CPU time was being spent. It also seems to focus on vertical layering more than horizontal splitting, being a photo sharing website I would have thought there was a lot of CPU intensive photo manipulation or something they can split off to services on the side that doesn't need to be done in real time.