Introduction to System Architecture and common architecture patterns

Alberto Basalo
5 min readJan 24, 2022

--

Once the domain problem is understood it is time to think about the proposed solution.

Here starts the technical job, the one I like the most. But before talking of code there is a much-needed high-level view: the system architecture to create the design of the complete system.

Photo by Denys Nevozhai on Unsplash
System architecture, designing solutions.

🏗️ System Architecture

Under this grand title hides a simple concept: knowing what are you going to build. It is not yet time to know how we are going to build.

But we must at least identify the large building blocks necessary to solve the detected problems. Like in the real world, know if we are building a family house, a school, or a corporate building.

🐲 Warning, here be dragons

Traditionally software was created following a strict life cycle: analysis, design, code, test, and deployment. The waterfall model.

Even when these phases make sense they should be applied iteratively. In most cases creating a short cycle that generates value in each loop.

So we should avoid a deep and long design phase that dictates the ongoing future of the project: the so-called Big Design Up-Front. Instead, only a big picture of the proposed solution, as an experiment with flexibility in mind.

🤔What are we going to build?

At this point, you must make a decision about what kind of software are we talking about.

  • Is it just a web application or involves any mobile or desktop deployments?
  • Does it need physical tiers or just a monolith?
  • And what about data?
  • Can we foresee if it will be an intake-intensive system or on contrary a read-focused solution?
  • How will be the communication with external systems if any?

The divide and conquer paradigm is always here to help; so start by cutting the bigger pieces.

🚩Physical and technological tiers

Almost any software system is composed of three complementary actions:

🧑‍🦱 Interacting with the user

🚚 Processing information

📦 Storing data

Any of them can run on the same machine or different machines. Is up to you. Nowadays the three tiers architecture is a common approach to any line of business solution.

3️⃣ The three-tier architecture

Before you jump right into the three-tier architecture, make sure you need them all. Think carefully about whether your solutions need all three different tiers in the stack.

Obviously, this architecture has great long-term benefits for any complex system. By developing and maintaining each level as independent modules on separate platforms, you could evolve any of them without affecting the solution as a whole.

And since technology (and user needs) doesn’t advance at the same rate, it might be possible to modernize your front-end by relying on your trusted and beloved database.

🧑‍🦱 Presentation Tier

The very top layer that interacts with the end-users. Most of the time is a web application executed in a browser. But, for sure, could be a mobile, desktop, a CLI application, or even all of them.

🚚 Application Tier

Contains the business logic and is in charge of validation, transformation, and main data processing. Could be composed up of one or several processes called services.

📦 Data Tier

Here is where the information lives. Data is kept on file systems or databases of several kinds; being transactional and documental the most widely used.

🏛️ Architectural patterns

There are decisions to take in every tier, with no silver bullets or correct answers. To help you with some of those choices, you can rest on proven and named solutions: we call them patterns.

As always, before choosing or even knowing the existence of any pattern you should understand carefully the problem you have to solve and the user stories you are going to fulfill. Slice them horizontally to get a glimpse of the involved technologies and then slice them again vertically to narrow the scope.

But hey, you are here for the patterns, so here we go:

🪨 Monolith

The tier is developed and deployed as one, with the benefit of ease of operation and less overhead.

On the other hand, any minimal change requires a full deployment. And if some feature needs a boom to scale, then the whole tier will be scaled at once. Obviously, all the codebase of the tier must be written on the same technology.

🏪 Service-oriented

Is a refinement that allows to develop and deploy a subsystem of any tier independently. Maybe a functional subdomain (🌮 vertical layering) or a technical abstraction (🥪horizontal layering).

Is a cost-efficient starting point for complex and long-term evolutionary situations.

📡 Event-based

When some features are more expensive or take longer to complete, you can scale and improve the overall system by taking an asynchronous approach.

In this particular scenario, some processes will be executed at a later time, allowing the system to run without waiting for a slow request to finish.

On most web frameworks this is included as a reactive event publish and subscribe paradigm.

On back end systems usually involves some kind of message queue and the application of Command Query Responsibility Segregation

In certain situations, this pattern even reaches down to the data level, suggesting the use of multiple databases specialized for command processing and query fetching.

🤖 Microservices

The ultimate evolution of this architecture generates multiple independent services each one with its own database. Being this is the critical difference with service-oriented, who share the same data tier.

You can have a microservice architecture with just a couple of small services.

But usually, you will evolve and refine your system by creating a different service (remember, with its own database) for each subdomain.

And you’ll keep refining until you end up with one service per user story; which means you have to manage and orchestrate hundreds of potentially totally different applications. But any of them could be developed and deployed at their own pace.

So, here’s a first look at system architecture and the role of software architecture. A piece of necessary knowledge for each member involved in modern and agile development teams.

--

--

Alberto Basalo

Advisor and instructor for developers. Keeping on top of modern technologies while applying proven patterns learned over the last 25 years. Angular, Node, Tests