‫[Michael Pogrebinsky] Hey, welcome back.
‫In this lecture, we're going to learn
‫our first architectural pattern:
‫The Multi-Tier Architecture.
‫We will first get a general introduction to this pattern,
‫and later, we will proceed to learn
‫about some of the most common variations of this pattern.
‫Most importantly, by the end of the lecture,
‫we'll know when to apply this pattern to our system
‫and when to seek other solutions.
‫So let's start with a general introduction
‫to the Multi-Tier architectural pattern.
‫The Multi-Tier Architecture organizes our system
‫into multiple physical and logical tiers.
‫The logical separation limits the scope of responsibility
‫on each tier,
‫and the physical separation allows each tier to be deployed,
‫upgraded, and scaled separately by different teams.
‫It's important to point out that, although occasionally,
‫you may hear people using the terms
‫Multi-Tier and Multilayer architecture interchangeably,
‫they are, in fact, two different concepts.
‫Multi layered architecture usually refers
‫to the internal separation inside a single application
‫into multiple logical layers or modules.
‫However, even if the application
‫is logically separated into multiple layers,
‫at runtime, it will run as a single unit
‫and will be considered as a single tier.
‫When we talk about Multi-Tier Architecture,
‫we mean that the applications in each tier
‫physically run on different infrastructure.
‫Besides the benefits of logical and physical separation
‫that allows us to develop, update
‫and scale each tier independently,
‫there are a few restrictions in this architectural pattern
‫that simplify the design.
‫The first restriction is that each pair of applications
‫that belong to adjacent tiers communicate with each other
‫using the Client-Server Model,
‫which is a perfect model for RESTful APIs, for example.
‫The second restriction discourages communication
‫that skips through tiers.
‫This restriction keeps the tiers
‫loosely coupled with each other,
‫which again, allows us to easily make changes to each tier
‫without affecting the entire system.
‫So now that we got an introduction
‫to the Multi-Tier architectural pattern,
‫let's talk about one of the most common
‫Multi-Tier architectural variations,
‫which is the Three-Tier Architecture.
‫The Three-Tier Architecture, to this day,
‫is one of the most common and popular architectural patterns
‫for client-server, web-based services.
‫In the Three-Tier Architecture,
‫the top level tier contains the user interface,
‫and is often referred to as the Presentation Tier.
‫The responsibility of the Presentation Tier
‫is to display information to the user
‫and also take the user's input
‫through a graphical user interface.
‫Examples of the Presentation Tier include
‫a webpage that runs on the client's browser,
‫a mobile app that interacts with the user
‫on a mobile device,
‫or a desktop GUI application.
‫The Presentation Tier normally does not contain
‫any business logic for many reasons.
‫One of those reasons, that applies specifically to code
‫that runs in the client's browser,
‫is that this code is directly accessible
‫and visible to the user.
‫Since, generally, we don't want the user to see
‫and potentially change our business rules,
‫it is an anti-pattern to include any business-specific logic
‫in the Presentation Tier in general.
‫The second, middle tier, is called the Application Tier
‫or sometimes also referred to as the Business Tier
‫or the Logic Tier.
‫The Application Tier is the tier that provides
‫all the functionality and features
‫that we gathered from our functional requirements.
‫This tier is responsible for processing the data
‫that comes from the Presentation Tier
‫and applying the relevant business logic to it.
‫The last tier is the Data Tier.
‫This tier is responsible for storage and persistence
‫of user and business-specific data.
‫This tier may include files
‫on our file system, and most commonly,
‫it includes a database.
‫So, what makes the Three-Tier Architecture
‫such a popular choice?
‫One of the reasons that the Three-Tier Architecture
‫is so popular is because it fits
‫a large variety of use cases.
‫Almost any web-based service fits this model,
‫be it an online store, a news website,
‫or even a video or audio streaming service.
‫It's also pretty easy to scale horizontally
‫to take large traffic and handle a lot of data.
‫And let's see how.
‫The Presentation Tier, of course,
‫does not need any special scaling
‫because it simply runs on the user's devices,
‫so it essentially scales by itself.
‫If we keep the Application Tier stateless,
‫like we should when we use something like a REST API,
‫we can then easily place the Application Tier instances
‫behind a load balancer and run as many instances as we need.
‫And finally, the database can also be scaled very easily
‫if we use a well-established distributed database,
‫which we can scale by using the techniques
‫that we already learned,
‫such as replication and partitioning.
‫Finally, this architectural style
‫is very easy to maintain and develop
‫because all the logic is concentrated in one place,
‫in the Application Tier,
‫where all the back end development actually happens.
‫And we don't need to worry about the integration
‫of multiple code bases, services or projects.
‫So, when does the Three-Tier Architecture
‫stop working for us?
‫Well, the Three-Tier Architecture has one major drawback,
‫which is exactly the reason
‫why it's so popular and easy to apply.
‫This drawback is the monolithic structure of our logic tier.
‫Since, as we mentioned earlier,
‫we do not want to have any business logic
‫in the Presentation Tier, and of course,
‫we can't have any logic at all in the data tier,
‫we are in a situation where all our business logic
‫is concentrated in a single code base
‫that runs as a single runtime unit.
‫That has two implications.
‫The first implication of this drawback
‫is that each of our application instances
‫simply becomes too CPU intensive
‫and starts consuming too much memory.
‫This makes our applications slower and less responsive,
‫especially with memory-managed languages like Java or C#,
‫which, as a result, will have much longer
‫and more frequent garbage collections.
‫All those issues may require us
‫to start upgrading each computer we run our application on
‫and we already know that vertical scaling
‫is both expensive and limited.
‫The second implication of the monolithic nature
‫of the Application Tier is Low Development Velocity.
‫As our code base becomes larger and more complex,
‫it gets much harder to develop, maintain and reason about.
‫And hiring more developers will not add too much value
‫because more concurrent development
‫will simply cause more merge conflicts and higher overhead.
‫We could, somewhat, mitigate this problem
‫by logically splitting the application's codebase
‫into separate modules.
‫However, those modules will still be
‫somewhat tightly coupled
‫because we can release new versions of those modules
‫only when the entire application is upgraded.
‫So, in other words, the organizational scalability
‫of the Three-Tier Architecture is somewhat limited.
‫So in conclusion, the Three-Tier Architecture
‫is the perfect choice for companies
‫whose code base is relatively small and not too complex,
‫and also, it's maintained by a relatively
‫small team of developers.
‫This includes early-stage startup companies,
‫as well as well-established companies
‫that fit those criteria in terms of the size
‫of the codebase and the organization.
‫In addition to the Three-Tier Architecture,
‫there are a few other variations
‫to the Multi-Tier architectural pattern.
‫So, let's take a look at a few of them.
‫Besides the obvious One-Tier Architecture,
‫which is simply a standalone application,
‫we have the Two-Tier architectural pattern,
‫which is maybe less common than the Three-Tier Architecture,
‫but is still pretty popular.
‫In the Two-Tier Architecture,
‫the top-level tier includes
‫both the presentation and the business logic
‫and usually runs as a feature-rich mobile
‫or desktop application.
‫The second tier is the data tier, which,
‫just like before, takes care of the storage and persistence
‫of the users and business data.
‫The Two-Tier Architecture eliminates the overhead
‫of the middle Logic Tier and usually provides a faster
‫and more native experience to the users.
‫A few examples of the Two-Tier Architecture use cases
‫include desktop or mobile versions of a document,
‫image, or music editor that provides all the functionality
‫and the graphical interface on the user's device,
‫while all the storage and backup takes place
‫on a remote server that belongs to the company
‫that provides this application.
‫On the other end of the spectrum,
‫we can have a fourth tier
‫in between the Presentation Tier and the Business Tier,
‫which separates some of the functionality
‫that doesn't belong in either of those tiers.
‫For example, if we support multiple client applications
‫in the Presentation Tier that have different APIs to us
‫or have different data and performance requirements,
‫we can introduce something like an API Gateway Tier
‫that can take care of security, API, and format translation,
‫as well as caching.
‫Having more than four tiers is extremely rare
‫because more tiers, normally, do not provide much value
‫and simply adds additional performance overhead.
‫This overhead comes from the restriction
‫against bypassing tiers,
‫which otherwise, would lead to tight coupling.
‫So now, every request from the client
‫has to pass through multiple services,
‫which can increase the response time for the user.
‫However, we rarely need to pass every request
‫through so many services.
‫So in the following lectures,
‫we will look at other and better options
‫of organizing our system
‫if we need to split our code base into multiple components.
‫In this lecture,
‫we learned about the first architectural pattern,
‫the Multi-Tier Architecture.
‫We learned about its general structure,
‫which splits our system architecture
‫into multiple logical and physical tiers,
‫which allows us to develop, upgrade,
‫and scale each tier completely independently.
‫After that, we talked about the most common variation
‫of the Multi-Tier Architecture,
‫which is the Three-Tier Architecture.
‫More importantly, we talked about the use cases,
‫the scale, and the complexity of the code base
‫that best fits this architectural model,
‫and when we should consider other alternatives.
‫And finally, we concluded with a few other variations
‫of the Multi-Tier Architecture,
‫the Two-Tier Architecture and the Four-Tier architectures,
‫which are also very common.
‫I'll see you soon in the next lecture.