Overview:

It’s time to design your application! Whether or not you know how to write code, the real question is: how do you fit together all the pieces of the puzzle? In developer jargon you might call this a “stack”.

In this guide we will discuss the core concepts, pros, and cons, of the incredibly popular 3-tier architecture. For many applications, including websites and mobile apps, this is the system design of choice. Let’s find out why.

Requirements:

  • Basic understanding of software vocabulary
  • Familiarity with network concepts
  • ~5 minutes

Parts of the Architecture:

The 3-tier architecture is composed of distinctive parts that are decoupled from one another, allowing individual development and maintenance. The three tiers – often called “layers” – of the architecture. This design consists of:

  • Interface layer
  • Application layer
  • Data / Storage layer
Core Layers

Interface layer

In most cases, an end user consumes the interface – often referred to as the “UI” or user interface. Its main purpose is to collection input and to display data provided by other layers.

Interfaces come in many styles, but, serve the same purpose. A few examples of common interfaces are: Websites, Mobile Apps, Desktop Apps, and even a command line tools. To learn how to develop a quick Flutter mobile app, check out this guide.

Application layer

The “server-side” or “backend” the application layer exposes functionality via an API that is consumed by the interface layer. As the application layer is obfuscated from end users, this is where most of the business logic exists. You can think of it as the part of the project that does all of the work.

Because the application layer runs on a server and not on client devices, therefor, the languages and frameworks used to create the application layer are usually quite different from languages used for developing the UI.

Java, PHP, Python, NodeJS, Kotlin, Go, and Dart; are examples of languages that are commonly used in the application layer. For more information about Kotlin, check out these tutorials for beginners.

Data layer

Finally, the last layer. The data layer is the foundation of your project and is responsible for storing your projects data, metrics, and configurations. Although this is not the most visually appealing of the three layers, a successful architect will pay very close attention to the use cases when getting this set up.

Depending on the use case, the data layer can completely make or break the project. Consider a project that must query for geographical data; this is a very difficult and computationally expensive task for a relational database, however, this task is something that MongoDB can do very quickly.

In summary, the data layer is your database technology. The number of viable database options has exploded in the last few years. Partly, this is due to the number of non-relational databases that have been created in the last few years.

Traditional database technologies might include: MS SQL, MySQL, and Postgres. More “modern” NoSQL (non-relational) databases include: HBase, Cassandra, and MongoDB. In addition to the previous options there exists an entirely different realm of caching solutions.

Example of 3-tier architecture

Our example project is a mobile application that reminds the user when they need to water their house plants. To do this our project will have a mobile interface, application layer to track timers and lookup plant data, and finally, a database that stores all of the plant and user data.

For this project a sample stack could be:

  • Flutter – Dart based mobile app framework – as an interface
  • Spring Boot – Java or Kotlin based framework for business logic – as the application layer
  • MongoDB – NoSQL database allowing flexible queries – as the data layer

Considerations:

Pro:
  • Individual parts of the project (layers/tiers) are decoupled
  • Each layer provides an opportunity to pick a different technology that is most appropriate for the use case
  • Well documented and accepted architecture
  • Helpful for learning and improving “full-stack” skills
Con:
  • Separation of projects requires potential maintenance at all layers
  • Data security and authentication/authorization need to be evaluated at each layer
  • Requires a small team or “full-stack” development skills

That’s it! You have made it to the end of this guide on 3-tier architectures. If you enjoyed this content and would like to learn more, check out some of the other articles about specific languages and technologies.

Questions? Concerns? Let me know!