Example of 4-Tier (for N-Tier) Architecture?

I'm leaning towards less abstract and more practical explanation that answers the question: "How and why do I want to split my system into tiers and where do I place them on the servers?"

Essentially, when you create a simple website that uses a database, you already have 3-tiers "out of the box":

• data tier - the database. But if you are using a short-lived memory cache or file system then we might argue if that can be considered a "tier" or not.

• application tier - the code that executes on your server(s).

• presentation (or client) tier - the code that executes on the client's machine and presents the results to the client

Now, how do we get the 4th tier?

Most probably, there is no need to split the client tier. It's on the client's device and we want to keep it as simple and efficient as possible.

Could we split the data tier? I have seen some systems with APIs around databases, Azure blobs, file systems etc. to create some subsystem that could be considered a tier. But is that still the same data tier (a.k.a fundamental services tier) or can we consider it a separate entity? And if we separate it out, will it be on the same physical (or virtual) server as our database, so we can protect the data from direct access?

However, in most cases, it's the application layer that gets split.

One part is still named application tier. It becomes an internal API web application and lives in secured zone where it can access the database. Nobody can access the database directly, but only through this application layer.

The other part becomes a consumer of the application tier APIs through some kind of a connection (HTTP client etc.). The consumer might be called presentation tier (confusing - wasn't it the same as client tier?), even if it itself has only JSON APIs and no any user-friendly formats.

But then the question arises: in which cases we, developers, might want to complicate our lives and split our web application into presentation tier and application tier, instead of keeping them as layers inside the same web application?

At serious workloads, a separate application tier might be good for scalability or it might be a requirement of security to deny database connectivity to the web server that is exposed to users (even the intranet ones).

I have seen some ambitious projects going for 4-tier from the start and then cursing themselves for overengineering things. You have to keep track of those internal connections, security, authentication tokens, keeping sockets under control (not opening a new HTTP connection on every request), avoiding accidental sharing of data of multiple parallel requests through carelessly created global HTTP client instance etc.

1. Fundamental Services : e.g. Database, Directory Services, File & Print Services, Hardware abstraction. This tier is increasingly called the platform.
2. Business Domain Tier : An Application Server such JavaEE including EJB, DCOM or CORBA Service Objects. Provide business functionality, increasing using SOA and Micro-services.
3. Presentation Tier : e.g. Java Servlets/JSP, ASP, PHP. This tier will increasingly include WebServices as proxies and adaptors for business tier services.
4. Client Tier : Thin clients like HTML Pages on Browsers and Rich Clients like Java WebStart & Flash.

• In Java EE it is common to divide the Business Domain tier into Data-Access (Entity Beans) & Business Services (Session Beans).
• In an Enterprise SOA (Service Oriented Architecture) the ESB (Enterprise Service Bus) would typically exist as an additional tier between tiers 1 & 2. It may be part of the platform provision.
• In Mashups you could have an aggregation tier between tier 3 & 4.

The move to being called N-Tier is a reflection of the move to increasingly componentised architectures from the older client-server to first 3-Tier then 4-Tier. The defining characteristic of a tier is a clearly defined interface with a separation of concerns.

Five minutes ago I've read an article of this https://www.nginx.com/blog/time-to-move-to-a-four-tier-application-architecture

Client is where you read it Api or your application back-end is where you assemble it .. Data aggregation.. Either goes through the jsons/xmls from outsourced things or queries on your database and lastly service tier is where you actually do the query on database or run function on big data or read GPS locations and maps from google ... That is how I see it in this case. It simply divided the data layer from three tier.

But this N-tier model is totally abstract so you can tear your infrastructure until you have some logically atomic parts only. Still dividing the previous structure.

That would depend on what you want to call a Tier. Each vertical of the Presentation layer could be called a tier.

• Mobile app or webpage frontend (one page Javascript and the like)

• The caching or CDN (Content Delivery Network) as another layer.

• Frontend or API tier

The business layer, could also be split if the service requires multiple microservices. For instance

• a Business process tier
• an Administration tier.

Then the data Layer split into:

• Database

• Data Lake

• Reporting

• Enterprise Service Bus

• Third party access data (where your app is connecting to other APIs)

For more see Cloud Application Architecture