Client-server architecture. SA for the little ones

Lyosik | Lead Systems Analyst (SA Lead)

Welcome to the block of articles for beginner systems/business analysts. Here we prepare to receive the coveted offer together

First, let's turn to the master of all knowledge – the great Internet – and find out what kind of beast this client-server architecture is.

So, as Google says

Client-server architecture is a model of interaction in a computer network where tasks are distributed between two main components: clients and servers.

From this it is clear that we need to understand two new concepts: client and server. Let's go.

Client – is a device on the user side that sends a request to the server to provide information or perform certain actions.

Server – is a more powerful computer or equipment designed to solve specific problems of executing program code, service functions at the request of clients, providing users with access to certain resources, storing information and databases.

Two-tier architecture

The simplest example of client-server architecture is the Two-tier architecture. This architecture is shown schematically below.

The peculiarity of such architecture is that the server stores all data in memory. But if the server crashes or simply reboots, all information will be lost. Everything that was in memory is erased when the system is turned off. And this is unacceptable from a business point of view.

Three-tier architecture

At the moment, three-tier or multi-tier architecture is still more common. *Move your gaze to the picture below*

Pros and Cons of Client-Server Architecture

Pros

  • A powerful server is cheaper than 100+ powerful client machines.

  • No code duplication. The main code is stored on the server.

  • Personal data is safe. The average user does not see anything unnecessary.

Cons

  • If one link fails, nothing works. If the server fails or the database is down, i.e. 1 link breaks, all clients are at rest.

But there is a solution to this problem.

In business-critical software, the architecture is complicated and even duplicated. A large company cannot afford downtime. So they use a cluster of servers – one is down, the rest are working.

So, we have come to an important topic. Let's stock up on hot tea and go.

Traffic distribution

The server can process a huge number of requests from different users. That is, there can be many clients, and if they need to exchange information with each other, they will have to do this through the server. Thus, the server gets another additional function – traffic control.

Let's remember a new concept:

Load balancer — is a special device or program that distributes incoming traffic (requests) between several servers.

The balancer can be placed before (on the frontend) or after (on the backend) the servers, depending on the system architecture.

For the balancer on servers, there are such concepts as hot and cold reserve.

  1. Hot reserve – when we have several servers working in parallel, and the balancer distributes the load between them.

Hot standby example

Hot standby example

  1. Cold reserve — when our second server is a backup copy of the first. All requests go to the first server, the second one is waiting.

Example of cold reserve

Example of cold reserve

Okay, we've sorted out the traffic distribution, let's take a sip of tea *or some fresh air* and move on to the next section.

Thick and thin client

In the world of information technology, there are two main approaches to building application architecture – fat client and thin client. Both approaches have their own unique characteristics, advantages and disadvantages, and their choice depends on specific requirements and tasks.

For the most impatient, the essence of these clients is as follows:

In a thick client, the main functionality lies with the user, in a thin client – with the server.

Well, now let's look at both types in more detail.

  1. Thin client – is a client application that minimizes the logic and functionality on the user side, delegating most tasks to the server. It depends on the server to provide most of the functionality.

Illustration of a thin client

Illustration of a thin client

Advantages of a thin client:

  • Easy to update.

  • Ease of control.

  • No development is needed in the application, the backend is enough.

Disadvantages of a thin client:

  1. Fat Client is a client application that contains a significant portion of logic and functionality directly on the user side. This type of client actively interacts with the server, but at the same time has significant autonomy.

Illustration of a fat client

Illustration of a fat client

Pros of a thick client:

Disadvantages of a thick client:

  • Requires installation.

  • Updates are complicated.

  • Double the development volume: both on the backend and in the application.

  • It is not possible to implement resource-intensive calculations.

  • Not all data can be transmitted openly to the client.

In practice, in fact, there is also another approach to building application architecture – hybrid.

  1. Hybrid – the backend can send both data and the algorithm of actions to the client. This method allows combining the advantages of both approaches by adding another layer of abstraction. It is possible to transmit from the backend both the necessary data and the algorithm for calculating the necessary values ​​in some form.

Illustration of the hybrid method

Illustration of the hybrid method

Now it's time to talk about ways to call the server.

Asynchronous and synchronous calls

But for starters, a little bit of theory from our beloved Google:

A server call is the process of sending a request to a server to retrieve data or perform a specific operation.

So, there are 2 ways to call the server:

  1. Synchronous call. When a server is called synchronously, the work on the client is stopped while the server function is executing. Once it is completed, the work on the client continues.

  2. Asynchronous call. With an asynchronous call, work is done in parallel.


As we understand, the client and server must interact with each other somehow. Here we will encounter new concepts, such as interaction protocols, integrations, data flows. But this is a fairly large block of information that deserves a separate article. By the way, in this separate article we will analyze synchronous and asynchronous calls in more detail.


Well, in conclusion, try to answer the following questions:

  1. Which client do you think is preferable and why?

  2. Which client to choose for a game, social network, banking application?

Clue

The thick client has a lot of unnecessary forms. The element is created even if it is not visible.

You can write your answers in the comments, we'll discuss it together 🙂

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *