How Typical Web Databases Grow
Most web databases grow through a relatively predictable set of architectural choices in the typical application life cycle. At some point, a growing application just gets bigger than the architecture can support, and the next step is usually determined by the constraints on the system and the depth of understanding of the people who work on it. It's useful to talk about this progression, but I don't want you to peek too far ahead. Sometimes people decide that they're eventually going to be playing a certain end game, and they become determined to skip the intervening steps. This doesn't always go well.
One of the reasons the progression is predictable is that it's logical. Smart people, when presented with the same situation, will often think of and try a relatively small set of solutions.
Single Server
A typical application starts its life on a single database server. (Some even start their lives on a single server, period.) This is actually a really nice situation to be in, if you can pull it off. Having a single server has a lot of benefits:
There's only a single copy of the data. There's no question about whether you're working with incorrect or different data.
Configuration is easy. You hardcode your database's hostname into your configuration file, or even the application code, and you're done. (I know that none of you has ever done that, of course.)
It's cheap. There are no costs for redundant hardware and no extra networking equipment. And the hardware ...
Get Web Operations now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
