Chapter 2. Web Site Architecture
There are many trade-offs to make in designing a web site, which involve many possible components and configurations. What you need depends on what you’re trying to do; one size does not fit all. This chapter goes over the fundamental problems that everyone runs into.
There are a number of trade-offs to make in designing a web site architecture: state versus scalability, replication versus simplicity, synchronous versus asynchronous, connectionful versus connectionless, speed of development versus planning, and procedural versus object-oriented programming.
State Versus Scalability
Left to its own devices, a web site has no ability to remember individual users from one web transaction to the next. In such “stateless” web sites, users have no particular information that needs to be tracked. The web site has complete amnesia about your previous visits. It delivers the page without considering whether you’ve asked for it before or what other pages you’ve viewed.
Web sites that have no user state have no problem with scalability. Stateless web sites are easily replicated for scalability by load balancing across many servers, even if the content is dynamic (for example, a site that serves stock quotes or weather information), as long as the source of that dynamic data can be replicated. Since the web servers are all functionally the same, it does not matter if a user gets the home page from one server, then hits a different server when he clicks ...