Client and server architecture

Tactic, pattern, architecture

In the last two posts(Post 1 Post 2), I described about tactics: a solution to a single quality attribute/requirement (such as modifiability, security, testability, availability, performance) are ensured. Pattern is a higher level solution to multiple quality attributes, and unlike tactic, it has tradeoffs (since a pattern might do good for certain QA, but not other QA)

 

Architectural pattern (eg Client and Server architecture, MVC architecture) is different from design pattern (eg adapter pattern, singleton pattern, strategy pattern etc), in its scope. Architectural patterns are to do with subsystems and modules (system level, coarsegrained), while design pattern is for classes and templates (local, finegrained).

 

Architectural pattern: Client and Server architecture

We have clients and servers in the system, such that: 

- Clients only request to server, serveer responds.

- separates client from services it uses (factoring out common service to server)

- it's easy to add more clients, add service.

 

Additionally,

- Each client can depend on different servers

- There can be many servers serving for the same purpose (fascilitated by load balancer). so could be one central server, or multiple servers.

- some components can be both client and server.

- each client can act as a server.

- server doesn’t always have to ‘respond’: server might be able to register callback (notification procedure) to do something on the client

Client and server architecture satisfies multiple QA

high modifiability: can add more servers, change servers, do so without client noticing

high availability: related to modifiability (can replace server, direct connection to new server)

high performance: too many requests -> load balancer to send request to different servers

high security: just one point to apply security(server). firewall/intrusion attacks protection.

 

Note on performance: server can be bottleneck, but can be fixed if we have many servers