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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access