A. Application Architecture Styles
Type of
architecture
style
Characteristics
Appropriate Uses
Benefits
Challenges
N-Tier
The N-tier architecture is commonly divided into three
different tiers and these tiers are:
• Logic tier – coordinates the application,
performs calculations, makes decisions and
moves data between the two layers.
• Presentation tier – this tier is the user interface
and it translates tasks into something the users
can understand.
• Data tier – in this tier data and information are
stored and retrieved from a database or other
storage system. This information is passed to
the logic tier to be processed and then to the
user.
• The n-tier can be used for the creation of
simple web applications
• The migration of an application to the Azure
cloud with minimal refactoring
• The development of on-site cloud
applications
There are many benefits to using the n-tier
architecture. Some of these are the scalability of the
architecture, easy to manage, security measures put
into place and how flexible it is.
• Scalability – more tiers can be added if
needed without affecting the other tiers
• Management – each tier can be managed
separately, and modify them without
affecting the other tiers
• Security – each tier can be secured using
different methods
• Flexible – you can expand any tier in any
manner that you require to do so
• When the system becomes large, the
network security of the system will
be hard to manage as a whole
• The monolithic design of the
architecture prevents independent
deployment and release of features
• The middle tier can be used for CRUD
alone which introduces extra latency
to the system
Web-Queue-
Worker
The core characteristics of this architecture are the web
end front which will serve the requests of the client, a
worker which is responsible for performing the resource-
heavy tasks. A message queue is used to communicate
with the worker and the web front. Other characteristics
of the architecture include:
• One or more database systems
• A cache that stores values from the database
that can be read quickly
• Remote services such as SMS or email.
• For the use of managed services instead of
an Infrastructure as a service(IaaS)
• Applications that consist of a simple
domain
• Applications that consists of a long running
workflow or batch operations
• This architecture is easy to deploy and is
easy to manage
• It is an architecture that is easy to
understand
• No IaaS architecture to manage like in
the n-tier architecture
• The front end and the worker can be
scaled independently
• The front end and the worker can be
large without careful design and
monolithic components that are
difficult to maintain and update
• If the code modules and data
schemas are shared between the
front end and the worker, there will
be hidden dependencies
Microservices
Microservice architecture consists of a collection of
small, autonomous services. Each service is self–
contained and should implement a single business
capability. Each service is a separate codebase which is
managed by a small development team. These services
can be deployed independently and the services are
responsible for persisting their own data. The services
don’t share the same frameworks, libraries or
technology stacks.
• An organization or business that consists of
a small development team.
• For complex applications that need to be
highly scalable
• Applications with rich domains or many
other subdomains
• Granular scaling – services can be scaled
independently
• Small teams- teams are small and can
focus on one service and this small scope
makes code easier to understand
amongst the team.
• Independent deployment – services can
be updated without redeploying the
entire application and bug fixes are much
more manageable and less risky
• Data integrity – each microservice is
responsible for its own data
persistence and as a result data
consistency can be a challenge.
• Complexity–microservice applications
have more moving parts than a
monolithic application even though
each service is simple the whole
system as a whole is more complex
• Lack of governance – the application
can become hard to maintain with
the different amount of languages
and frameworks used and this can
lead to problems
CQRS
(Command and
Query
Responsibility
Segregation)
This architecture style separates read operations from
write operations.
This means that every method should either be a
command that performs an action or a query that
returns data. This type of architecture is especially tuned
• You can consider using CQRS for
collaborative domains where many users
access the same data.
• Try to only apply CQRS to those subsystems
• Security – it is easy to ensure that only
the right domains are performing writes
to the data
• Simple queries – when a complex view is
• Complexity – the idea of CQRS is
simple but it can lead to a very
complex application design
• Eventual consistency – if the read and
tracks the subscriptions whereas when an
the stream
