Web Operations

Database Strategy

I've been writing a lot about generalities, trying to lay the groundwork for a good architecture. Let's shift gears. Let's move from the abstract into the concrete and see how to choose an architecture that serves well for a lot of Internet architectures. I'll start with what I think are realistic requirements for a database architecture (remember, you can't have it all), and then tell you what I think are some reasonable and safe options to pursue.

Architecture Requirements

As always, you're much better off to define your requirements, and specifically, to document what's out of scope and therefore someone else's problem. If you have this clear, you'll do everyone a big favor. The sooner you decide who should focus on solving issues the sooner this person can budget and plan for it. So, let's create an imaginary web application as an illustration and list the requirements for it informally.

Our mythical application will be always-on, 24 hours a day. There will be spikes and peaks in the traffic. There'll be two daily peaks as the East and West coasts of the United States wake up. We will have high enough peaks that we'll be able to do maintenance operations in the slow periods, but we won't be able to go offline. We'll only be able to reduce our capacity to perform these operations. Downtime will directly affect the bottom line. In the future, we'll expand into Europe and Asia, thus making it even less feasible to take downtime. We'll have seasonal spikes, and we ...