The client/server architecture is a versatile, message-based and modular infrastructure that is intended to improve usability, flexibility, interoperability and scalability as compared to its earlier centralized, mainframe, time sharing computing.  A client is defined as a requester of services and a server is defined as the provider of services. A single computing machine can both act as a server and a client. 

Before going deeply into two-tier architecture, here comes a brief about the earlier computing architecture.

1.  Mainframe architecture - With mainframe software architectures, all intelligence has been found within the central host computer. Users interact with the host through a unintelligent terminal that captures keystrokes and sends that information to the host. Mainframe computing architectures are not tied to a hardware platform. Users can connect with the host through any sort of systems including PC or Unix workstations. The main stumbling block with this architecture is that it does not support any graphical user interface or access to multiple databases from geographically dispersed sites.

The two-tier client/server architecture is a good solution for distributed computing when work groups are defined as a dozen to 100 people interacting on a LAN simultaneously.  The application exists entirely on the client PC while the database sits out on a server machine. In this type of architecture, the full processing load is lying onto the PC while the more powerful server machine act as a traffic controller between the application and the database. 

This feature leads to very high utilization of the PC resulting in poor performance and there is a sharp increase in network traffic. This is a result of the server maintaining a connection via "keep-alive" messages with each client, even when no work is being done.  When the entire application is processed on a PC, the application is forced to make multiple requests to data source for data before presenting anything to the end user. These multiple data requests can affect the precious network performance. Thus there arises a very high inhibition on scalability, availability and performance on the system. Also in a typical two-tier client-server environment, programmers write applications that are closely tied to vendor-specific software. 

Another main problem with any two-tiered client/server approach is that of maintenance. If there is a small change effected in an application logic code, all the users accessing that code have to be taken off from the systems. As the days go by, this may lead some sort of confusion about which version of the software is being used and by whom. Thus performance degradation and maintenance issues are the two main bottlenecks prevailing in a two-tier architecture application apart from the issues such as lack of scalability and flexibility and a very high network traffic. 

In order to address the above-mentioned issues in an effective way, software developers community came with an evolutionary but effective and efficient solution referred to as "three-tier architecture". That is, an application can be separated into three logical layers, each with a well-defined set of  interfaces. The first tier is called as the presentation layer and it normally consists of a graphical user interface. The middle tier consists of the application logic and the third tier is the data layer. The three logical layers can lie in the same machine also through smart software configuration. 

Thus three-tier client/server applications employ an intermediary or middle-tier application server, which operates between client applications and the back-end databases. The middle tier composes business application logic code, which the user calls upon through the front-end graphical user interface to retrieve the desired data. The presentation layer on getting the data from the middle tier formats the data for displaying it to the user. This kind of separations brings a number of unique advantages such as flexibility and performance increment. Also multiple user interfaces can be built and deployed with out bringing any change to the application logic. 

There are a variety of ways of implementing this middle tier, such as using transaction processing (TP) monitors,  message servers, object request brokers (ORBs) or application servers. The middle tier can perform queuing, application execution, locating and connecting application objects and database staging.  If the middle tier provides queuing, the client can deliver its request to the middle layer and disengage because the middle tier will access the data and return the answer to the client. 

The third tier contains the data that is needed for the application.. The data can be from any source of information such an enterprise database like Oracle, MS SQL Server, a set of XML documents, a directory service like an LDAP server, or even any legacy and proprietary systems. 

This approach heavily improves those lacking points found in two-tier application. There are two fundamental motivations for using a three-tier architecture over a two-tier model:  

• Improved Scalability, availability, and performance
• Improved flexibility, and extensibility of business systems

These features are being achieved through managing back-end resources in a more effective and smart manner. There are some good resource management techniques such as pooling and clustering middle-tier servers. Pooling makes three-tier systems more effective by allowing more clients to share scarce resources like database connections, which reduces the workload on back-end servers. Clustering makes three-tier systems more available and scalable because multiple servers and resources can support fail-over and balance the word loads of a growing client population.

Three-tier systems are more flexible and extensible than their two-tier systems as the business logic and services such as security, persistence, transactions etc reside on the middle-tier and transparent to the client applications. This tends to make these services being applied automatically to client requests and any changes made in the business logic code do not reflect on the clients in any way. 

Still it has been found that three-tier methodology lacks some critical features such as reusability of application logic code and scalability. That is, there may arise a situation whereby a collection of application logic code results and they can not be reused  and also they do not communicate with one another. Thus there came a need for a viable architecture that mainly facilitates reusability of business logic as reusability phenomena has been found to reduce the cost of software development and the time to market and its quality is assured.

• the ability to update multiple different DBMSs in a single transaction
• connectivity to a variety of data sources including flat files, non-relational DBMSs and even  mainframe systems
• the ability to attach priority to transactions and to give robust security 

For systems with thousands of users, TP monitor technology has been one of the most effective solutions. 

The main limitations of this technology is that the implementation code has to be written in a low-level language such as COBOL and there is no visual toolsets to interoperate with the middle tier.

Thus came the notion of n-tier architecture. To turn a three-tier architecture into an n-tier system, the middle tier can be allowed to have multiple application objects rather than a single application. Each  of these application objects must have a well-defined interface which allows them to contact and communication with one another. An interface is actually brings an idea of contract. That is, each object states through its interface that it will accept certain parameters and return a specific set of results. Application objects uses their interfaces to do business processing.

With an n-tier architecture, one can have multiple applications using a common set of business objects across an organization. This promotes the standardization of business practices by creating a single set of business functions for the entire organization to access. If a particular business rule changes, then changes have to be made to only the business object and if need, to its interface also.