The difficult piece is durable state storage (typically a database). When you are just starting out, a big database of everything is probably good enough. Chose a solid, widely used data store (MySQL, Postgres, Mongo, Oracle, MSSQL, etc) and use it. Do as little in this layer as you can - it's going to be the most expensive and difficult to scale. Put your business logic elsewhere. Protect it from read spikes with a cache. Design your schemas carefully.
I disagree with some of this. In general the worst db scaling I have seen are ones with large numbers of simple queries based on the idea of doing as little in the db as you can. Instead I would suggest two principles regarding making the db a little more scaling-friendly:
1) Everything that needs to be queried together should be queried together. Don't do lots of round trips and simple queries.
2) Don't do stuff in your database that it isn't designed to do. Write good queries, but don't do things like send emails from the db backend.
A corollary here is that you should write your queries with performance in mind but not do too much premature optimization. For example, it's a lot easier to go from a group by to a sparse index scan (using a stored proc or a CTE) than it is to lock yourself into a sparse index scan from the get go.
In general, the four points you mention though are extremely well thought out. Following up on #4, although technology is important sometimes (esp. newly maturing technologies here like Postgres-xc), these are going to be far more useful where an app is well designed than where it is not. After all, if you don't know where the bottlenecks are in your app, you can't put effort into the right places to fix them.
Comments
The difficult piece is durable state storage (typically a database). When you are just starting out, a big database of everything is probably good enough. Chose a solid, widely used data store (MySQL, Postgres, Mongo, Oracle, MSSQL, etc) and use it. Do as little in this layer as you can - it's going to be the most expensive and difficult to scale. Put your business logic elsewhere. Protect it from read spikes with a cache. Design your schemas carefully.
I disagree with some of this. In general the worst db scaling I have seen are ones with large numbers of simple queries based on the idea of doing as little in the db as you can. Instead I would suggest two principles regarding making the db a little more scaling-friendly:
1) Everything that needs to be queried together should be queried together. Don't do lots of round trips and simple queries.
2) Don't do stuff in your database that it isn't designed to do. Write good queries, but don't do things like send emails from the db backend.
A corollary here is that you should write your queries with performance in mind but not do too much premature optimization. For example, it's a lot easier to go from a group by to a sparse index scan (using a stored proc or a CTE) than it is to lock yourself into a sparse index scan from the get go.
In general, the four points you mention though are extremely well thought out. Following up on #4, although technology is important sometimes (esp. newly maturing technologies here like Postgres-xc), these are going to be far more useful where an app is well designed than where it is not. After all, if you don't know where the bottlenecks are in your app, you can't put effort into the right places to fix them.