Benefits and Challenges of Layered (N-Layer)

Architecture Design our E-Commerce application

with Layered Monolithic
Architecture

•Layered (N-Layer) Architecture

8
0
Problem: Code Become Too Complex Over
Time
Problems
● Become Complex over time

● Hard to Understand Codes

● Need Code Organization

Solutions
● Separate UI, Business and

Data Layers as logical

layers
● Layered Architecture

● SOLID Design

2
Learn: Layered (N-Layer)
Architecture
 The layered architecture pattern is the most
commonly used architecture pattern. Known as
the n-tier architecture style or the multi-layered
architecture style.
 Organize the components of an application with
similar functionalities into horizontal logical
layers. Each layer performs a specific role within
the application.
 Still using Monolithic architecture separating
horizontal logical layers, components are
interconnected but don't depend on each other.
 Organizing code for separation of concerns
 Layers of isolation that layers can be modified
and the change won’t affect other layers.

3
Components of a Layered
Architecture
 Presentation Layer
Responsible for user interactions with the
software system, for example, a web app.
 Application/Business Layer
Handles aspects related to accomplishing
functional requirements including use case
implementations.
 Database Layer
Responsible for handling data, databases,
such as a SQL database.

4
Design principles - Separation of Concerns
(SoC)
 Separation of concerns(SOC) is one of the
core software design principle
 Separation of concerns is a design principle for
separating a computer program into distinct
sections
 Isolate the software application into
separate sections, manages complexity by
partitioning the software system
 Distinguish between the concepts of layer and
tiers with certain responsibilities.
 Elements in the software should be unique
 Limits to allocate responsibilities
 Low-coupling, high-cohesion

5
Design principles -
SOLID
 Single Responsibility
Each of your components or modules
should responsible only one
functionality.
 Open-Closed Principle
When we design the system, it should able to
extend without changing existing
architecture.
 Liskov Substitution Principle
Systems can be substitute each other easily. In
our case we can use plug-in services that we
can shift them easily.
 Interface Segregation Principle
States that no code should be forced to
depend on methods it doesn't use.
 Dependency Inversion Principle
States that high-level modules should not 6
depend on low-level modules; both should
Before Design – What we have in our design toolbox ?
Architectures Patterns&Principles Non-FR • FR
• Monolithic • KISS • Availability • List products
• YAGNI • Small number • Filter products as
Architectu per brand and
• Seperation of of Concurrent
re categories
User
Concerns (SoC) • Put products into
• Layered
• Maintainability
Architecture • SOLID the
• shopping cart
• Apply coupon for
discounts
• Checkout the
shopping cart and
create an order
• List my old orders
and
• order items history
7
Design: Layered Monolithic Architecture
Steps

8
Design: Layered Monolithic
Architecture

9
Way of Learning – The Course
Flow

• Architecture • Fill Design Toolbox • Apply Software Tools

• Identify
Approaches • Design Initial • Application
Clearly
• Patterns version Frameworks
• Principles & Best • Databases
Practices

• What's wrong with this

architecture ?
• how we can improve this current
design ?

10
Adapt: Layered Monolithic
Architecture
Java World
● Apache Web

Server
● J2EE

● MySQL

.NET World
● IIS Web Server

● Asp.Net

● SQL Server

11
DEMO: Layered Monolithic Architecture Code
Review

12
Way of Learning – The Course
Flow

• Architecture • Fill Design Toolbox • Apply Software Tools

• Identify
Approaches • Design Initial • Application
Clearly
• Patterns version Frameworks
• Principles & Best • Databases
Practices

• What's wrong with this

architecture ?
• how we can improve this current
design ?

13
Evaluate: Layered Monolithic
Architecture
Benefits
● Easy Development, Debug and

Deploy
● Horizontal Logical Layers

● Separation of Concerns

Drawbacks
● Layers Dependent each other

● Highly Coupling

● Hard to maintanance

● Complexity of codebase

●Hard to Change libraries; i.e.

Change orm tool with different

library Requires to modify
business layer.

14
Way of Learning – The Course
Flow

• Architecture • Fill Design Toolbox • Apply Software Tools

• Identify
Approaches • Design Initial • Application
Clearly
• Patterns version Frameworks
• Principles & Best • Databases
Practices

• What's wrong with this

architecture ?
• how we can improve this current
design ?

15
Problem: Highly Coupling Dependent
Layers
Problems
● Layers are highly coupled and

dependent each other

● Code Organization hard to

maintain
● Locking of frameworks hard to

change

Solutions
● Clean Architecture

● The Dependecy Rule

16
Event-Driven Microservices
Architecture

Asynchronous communication, Decoupled

communication Event Hubs
Stream-Processing
Real-time
processing High
volume events 54
6
Problem: Handle Millions of
Events Across Microservices
Considerations
● What if we have thousands of microservices that

need to
communicates with millions of events ?
● If multiple subsystems must process the same

events
● Required Real-time processing with minimum

latency.
● Required complex event processing, like pattern

matching
● Required process high volume and high velocity of

data,
i.e. IoT apps.
Problems
● Decoupled communications for thousands of

microservices
● Real-time processing Mehmet
18
● Handle High volume events
Ozkaya
Introduction - Event-driven
Architecture
 Microservices architectures are designed to be highly
modular and flexible, that can be scaled and managed
separately and use of APIs to communicate between
services.
 Event-driven architecture, microservices can
communicate by publishing and subscribing to events,
than directly calling each other's APIs.
 Event-driven microservice architecture is means
communicating with microservices via event messages
and we can do asynchronous behavior and loosely
coupled.
 Instead of sending request when data needed, services
consume them via events.
 Huge Innovations on the Event-Driven
Microservices Architectures;
 Real-time messaging platforms, stream-processing,
Mehmet
event hubs, real-time processing, batch processing, Ozkaya
19

data intelligence.
Event-Driven Microservices
Architecture
 Event-driven microservices architecture, services
communicate with each other by publishing and
subscribing to events.
 When a service needs to communicate with another
service, it publishes an event to a message queue or
event bus. Other services can then subscribe to that
event and take appropriate action when the event is
received.
 Asynchronous communication
Allows services to communicate asynchronously.
Service can publish an event and continue processing
without waiting for a response from the other service.
 Decoupled communication
Decouples the publisher and subscriber, allows to
evolve independently without affecting each
other.
Mehmet
20
Ozkaya
Event-Driven Microservices Architecture -
2
 Real-time processing
Support real-time processing, as events are published
and consumed as soon as they occur. Need to react to
events in real-time, such as in systems that use CDC
to track changes to a database.
 High volume events
Well-suited to handling high volume events, as they
can scale horizontally by adding more event
consumers as needed. Can be scaled independently
to handle increased load.
 Responsible business capability
Each service is responsible for a specific function or
business
capability.
 Services communicate with each other by publishing
and subscribing to events, that make it easier to build
and maintain complex systems.
Mehmet 55
 Allows to work on different parts of the system in Ozkaya 0
Real-time Processing and High Volume
Events in Event-Driven Microservices
Architecture
 Real-time processing
Real-time processing is achieved by using a message queue or event bus to publish and
consume events as they occur.
 When an event is generated, it is published to the message queue or event bus and made
available to any interested subscribers.
 Allows you to react to events in real-time, as they are published and consumed as soon as
they occur.
 When need to perform real-time analytics or trigger actions based on changes to the data.
 High Volume Events
Using a message queue or event bus that can handle high volumes of events and distribute
them to
multiple consumers.
 When you have a system that generates a large number of events, use a event bus to
distribute those events to multiple consumers, that can process events in parallel.
 Allows you to scale up the number of event consumers as needed to handle increased
load. Mehmet
22
Ozkaya
 Event-driven microservices architectures to process events in real-time and scale to
Event Hubs and Event Streaming
in Event-Driven Microservices
Architecture
 Event Hubs
Act as a central hub for data ingestion and distribution, allowing microservices to publish
and subscribe to data streams.
 Each microservice publish its data to an Event Hub. Other microservices can then subscribe
to the Event Hub and consume the data as needed.
 Communicate with each other in real-time, that needs to be highly reliable and scalable.
 Event Streaming
Allows you to capture and process a stream of events in real-time. Publish and consume
events as they occur.
 Allowing to build real-time data pipelines that can process and analyze data as it is being
generated.
 One common use case for Event Hubs and event streaming in microservices architectures
is real-time analytics.

Mehmet
23
Ozkaya
Use Cases of Event Hubs and Event
Streaming
 Use Case – Customer Purchase on E-Commerce
E-commerce website that generates a large number of events as customers browse
and purchase products.
 Using event streaming, build a real-time analytics pipeline that processes these events as
they occur and generates insights in real-time.
 This could include tracking customer behavior, identifying trends and patterns, and triggering
actions based on changes to the data.
 Use Case – Data Synchronization
Different services may need to access the same data, and not be able to access each other's
databases
directly.
 Using event streaming, we can build a data synchronization pipeline that captures changes
made to the data and streams them to other services in real-time. Ensures to access the
most up-to-date data.
 Event Hubs and event streaming is a powerful tool for building real-time data pipelines in
microservices architectures that provides flexible platform for data ingestion and Mehmet
distribution. Ozkaya
24
Real-world Examples of Event-Driven
Microservices
 E-commerce application we have a few microservices
like:
customer, order, payment and products.
 Customer create orders with some products and, if the
payment is successful, the products should be
delivered to the customer.
Events
 a customer creates an order
 the customer receives a payment request
 if the payment is successful the stock is updated and the order is
delivered
 if the payment in not successful, rollback the order and set order
status is
not completed.
 This is more humanly readable and, if a new
business requirement appears, it is easier to
change the flow.
Mehmet
 Microservices will only care about the events, not 25
Ozkaya
about the other microservices, process only events
Traditional Event-Driven Microservices
Architecture

Mehmet
26
Ozkaya
Evolved Event-Driven Microservices
Architecture
 Huge Innovations on the Event-Driven Microservices Architectures.
 Real-time messaging platforms, stream-processing, event hubs, real-time processing,
batch processing, data intelligence.
 Event-Hubs is huge event store database that can make real-time processing.

Mehmet
27
Ozkaya
Kafka Event-Driven Microservices
Architecture

Mehmet
28
Ozkaya
 Before Design – What we have in our design toolbox ? -
Old
Architectures Patterns&Principles Microservices Data Microservices FR
• Microservices The Database- Choosing Database Distributed • List products
• per- Service • The Shared Database Transactions • Filter products as
Architecture Pattern Anti- pattern, per brand and
• SAGA Pattern
• Polygot Relational and NoSQL categories
Databases • Choreography and
Persistence • Put products into
scalability Orchestration-based
• CAP Theorem– the shopping cart
• Decompose SAGA
• The Scale Cube Consistency, •
services by Apply coupon
Availability, Partition • Compensating for discounts
• Microservices • Checkout the
Tolerance Transaction Pattern
Decomposition cart and create an
shopping
Pattern • Data Partitioning: • Dual-Write Problem ordemy old orders
• List
• Microservices Horizontal, Vertical and • Transactional and
Communicatio Functional Data Outbox order items history
ns Patterns Partitioning Pattern
Non-FR
• Microservices Data • Database Sharding • CDC - Change Data
• Pattern • High Scalability
Management Materialized View Capture
Patterns • Microservices
Pattern
CQRS Design Data • High Availability
• Microservices Commands&Queries
Pattern • Millions of
Uhsmeert 55
Distributed • Event Sourcing MeConcurrent 8
Ozkaya
 Before Design – What we have in our design toolbox ? -
New
Architectures Patterns&Principles Microservices EDA Non-FR FR
• Microservic • The Database- • Asynchronous, • High Scalability • List products
es per- Service Decoupled • Filter products as
• High Availability
Architecture Pattern communication per brand and
• Millions of categories
• Event-Driven • Polygot • Event Hubs
Concurrent User •
Microservices Persistence Put products into
• Stream-
Architecture • • Independent the shopping cart
Decompose Processing
Deployable • Apply coupon
services by
• Real-time for discounts
scalability • Technology • Checkout the
processing
• agnostic cart and create an
shopping
The Scale Cube
• High volume order
• Data isolation • List my old orders
• Microservices events
and
Decomposition • Resilience and order items history
Pattern Fault
• isolation
Microservices
Communications
Patterns
• Microservices Data
Mehmet
Management Ozkaya
30
Patterns
Event-Driven Microservices
Architecture

Mehmet
31
Ozkaya
Adapt: Event-Driven Microservices
Architecture
Frontend SPAs
● Angular

● Vue

● React

API Gateways
● Kong Gateway

● Express Gateway

● Amazon AWS API

Gateway
Backend Microservices
● Java – Spring Boot

● .Net – Asp.net

● JS – NodeJS
Event Hubs Cloud Event Hubs
● Apache
● Azure Event
Kafka Hubs
● Apache
● AWS Kinesis Mehmet 56
● Oracle Event
Spark Ozkaya 1
Hubs
Way of Learning – The Course
Flow

• Architecture • Fill Design Toolbox • Apply Software Tools

• Identify
Approaches • Design Initial • Application
Clearly
• Patterns version Frameworks
• Principles & Best • Databases
Practices

• What's wrong with this

architecture ?
• how we can improve this current
design ?
Mehmet
33
Ozkaya
Evaluate: Event-Driven Microservices
Architecture
Benefits
● Event Streaming

● Real-time Processing

● High Volume Events

● Decouple services, increased Scalability

● Resilience

Drawbacks
● Increased Complexity, event-driven

makes your system more complex

design.
● Hard to Debugging

● Add latency to the event publishing

process
● Integration into Distributed Transactions

● Difficult to set up and maintain

Mehmet
34
Ozkaya
Way of Learning – The Course
Flow

• Architecture • Fill Design Toolbox • Apply Software Tools

• Identify
Approaches • Design Initial • Application
Clearly
• Patterns version Frameworks
• Principles & Best • Databases
Practices

• What's wrong with this

architecture ?
• how we can improve this current
design ?
Mehmet
35
Ozkaya
Problem: Database operations are
expensive, low performance
Considerations
● Event-driven architecture comes with latency

when
publishing and subscribing events from the Event
Hub.
● Sync REST APIs communication make expensive

calls to a database that reduce performance.

● How can we make more faster that increase

performance of communications in Microservices

Architecture ?

Problems
● Slowliness and Low Performance Communication

● Latency when publishing and subscribing events

● Rest APIs make Database calls that are

Solutions
expensive, low
● Distributed performance
cache
● Storing frequently accessed data in a Mehmet 56
Ozkaya 5
distributed cache