Software Architecture Fundamentals

Architecture Patterns
Khoa Tran
[email protected]
TOPIC NAME
 Learning Goals
• Types of Architectural Asset
– Concept of Pattern, Architecture Pattern, Design Pattern,
Programing Pattern, Architecture Style, Pattern Language,
Reference Architecture, Reference Model, Application
Framework, Architecture Mechanism, Packaged Application,
Component & component library, Legacy Application,
Architectural Decision.
– Concept of Layers & Tiers
• Architecture Styles & Patterns
– Pipes and Filters
– Repository
– Client/Server (two-tiers; three-tiers; n-tiers)
– MVC (Model/View/Control)
– Service Oriented Architecture (SOA)
– Peer-To-Peer
• Other Architectures Patterns
– Architectural pattern for distributed systems: Broker
– Architectural pattern for distributed systems: Microkernel
2
 Make it different
• Day 1: Assest
Think Operation ? Think Scale
Key Resource for modern architect

• Day 2: C - day
Containerize / Cloud First / Cloud Native
Cloud Design Pattern

• Day 3: Composable Architect

Emerging Concept
Adoption Journey
What are the Secret Practices to Know

• Day 4: Exam

3
 Software Architecture
• What is Software Architecture?
– A set of structures that communicate the goals of the solution
– Singular task: to identify the structures, their elements, and the relationships
between them
– Properties and behaviors must be identified
– Architecture must define publicly visible properties that identify how
elements relate and interact with each other
– Architecture must have 4 attributes
• Elements
• Relations
• Properties
• Behavior

http://msdn.microsoft.com/en-
us/library/ms978007.aspx
4
 Architecting Solution

Select the Design the Document

Architecture Architecture the
Architecture

• Style: Client/Server; Message

Bus; SOA; Layered
Architecture; …
• Pattern: MVC,
Publish/Subscribe; Peer-to-
Peer; Request/Reply;…
• Build/Buy?

5
http://msdn.microsoft.com/en-
us/library/ms978007.aspx
Architecture = Design Decisions
Code etc • Decisions
• “Design “ decisions
• Architectural decisions
Software
Design • “Requirement constraints”

Software
Architecture

Requirements

A choice that is binding in the final product

6
 Types of Architectural
Assets

TOPIC NAME
 What Types of Architectural
Asset are there?
Reference Architecture Architectural Decision

Design Pattern Programming Pattern

Legacy Application Pattern

Architectural Mechanism Component Library

Pattern Language Component

Packaged Application Architectural Pattern

Development Method Architectural Style

Reference Model Application Framework

8
 Pattern
• [A pattern is] a common solution to a common problem
in a given context.[UML User Guide]
• Pattern types
– Architectural Patterns
• Distribution patterns
• Security Patterns
• …
– Design Patterns
– Programming Patterns
– Requirements Patterns
– Testing Patterns
– Project Management Patterns
– Process Patterns
– Organizational Patterns
– …
9
 Pattern
Question 1: Singleton. What is it ?

10
 Pattern
Question 2: Singleton. How to do it ?

11
 Pattern
Question 3: Is singleton an anti-patern?

12
 Anti Pattern
• ?

13
 Anti Pattern
• Silver bullet
• TDD = Tester Driven Development
• Golden Hammer

14
 Pattern vs Anti-Patterns
• Which to focus ?

15
 Principles Exercise
• Each group pick 1 principles to discuss
• After 10 mins, explain it to class

16
 Architectural Pattern
• An architectural pattern expresses a fundamental structural
organization schema for software systems. It provides a set of
predefined subsystems, specifies their responsibilities, and
includes rules and guidelines for organizing the relationships
between them.[Buschmann]
• Example:

17
Architectural pattern – Layers

18
 Design Pattern
• A design pattern provides a scheme for refining the subsystems
or components of a software system, or the relationships
between them. It describes a commonly-recurring structure of
communicating components that solves a general design
problem within a particular context.[Gamma]

19
 Programming Pattern
• An idiom is a low-level pattern specific to a programming
language. An idiom describes how to implement particular
aspects of components or the relationships between them
using the features of the given language.[Buschmann]

20
 Architectural Style
• [An architectural style] defines a family of systems in terms
of a pattern of structural organization. More specifically, an
architectural style defines a vocabulary of components and
connector types, and a set of constraints on how they can be
combined. [Shaw]
• Client-server
– Supports the physical separation of client-side processing (such
as a browser) and server-side processing (such as an application
server that accesses a database)
• Event-based
– Promotes a publish-subscribe way of working, applied
strategically across large areas of the architecture
• Pipes-and-filters
– A series of filters that provide data transformation, and pipes that
connect the filters. Examples include compilers, signal processing

21
 Pattern Language
• A pattern language defines a
collection of patterns and the
rules to combine them. Pattern
languages are often used to
describe a family of systems
• IBM Patterns for e-Business
– A set of architectural patterns
that describe various web-
based applications
– Includes a pattern selection
process that drives:
• Selection of a business,
integration or composite pattern
• Selection of application patterns
• Selection of runtime patterns
• Identification of product
mappings

22
 Reference Architecture
• A reference architecture is an architecture representation of a
particular domain of interest. It typically includes many
different architectural patterns, applied in different areas of
its structure .
• Examples include J2EE and .NET

23
 Reference Model
• A reference model is an abstract representation of entities,
their relationships and behavior, in a given domain of
interest, and which typically forms the conceptual basis for
the development of more concrete elements
• Examples include a business model, an information model
and a glossary of terms

24
 Application Framework
• An application framework represents the partial
implementation of a specific area of an application
• Most widely-known frameworks support user
interfaces
– Java Server Pages
– ASP.NET

25
 Architectural Mechanism
• Architectural mechanisms represent common
concrete solutions to frequently encountered
problems. They may be patterns of structure,
patterns of behavior, or both.[RUP]
• Often characterized as
– the mechanism for achieving X
– this element is underpinned by mechanism Y
• Examples
– Persistency mechanism
– Error logging mechanism
– Communication mechanism
– Shopping cart
26
 Packaged Application
• A packaged application is a large-grained
Commercial-Off-The-Shelf (COTS) product that
provides a significant amount of capability (and
reuse)
• Examples
– Customer Relationship Management (CRM) application
(e.g. Siebel)
– Enterprise Resource Planning (ERP) application (e.g.
SAP)
• The amount of custom development required is
greatly reduced
• Primary focus is on configuring the application
27
 Component & component
library
• Component examples
– GUI widget (such as a table)
– Service

• Component library examples

– Class libraries (e.g. Java class library)
– Procedure libraries

28
 Legacy Application
• A legacy application is a system that continues
to be used because the owning organization
cannot replace or redesign it
• Tends to be a focus on integration rather than
new development
• Often results in a focus on enterprise
application integration (EAI)

29
 Architectural Decision
• [Architectural decisions are] conscious design decisions
concerning a software system as a whole, or one or
more of its core components. These decisions
determine the non-functional characteristics and quality
factors of the system. [Zimmermann]
• Decision rationale may come from experience, method
or some other asset

http://www.iso-architecture.org/ieee-1471/cm/
30
 Basic Architectural Styles

TOPIC NAME
What is an architectural style?
• A family of systems sharing a pattern of structural
organization
• A vocabulary of components and connectors, with
constraints on how they can be combined (Garlan and
Shaw)
• A set of design rules that identify the kinds of
components and connectors that may be used to
compose a system or subsystem, together with local
or global constraints on the way the composition is
done (Shaw & Clements)
• A set of constraints put on development, namely a
collection of design decisions applicable in a given
context, specific to a particular system within that
context, and eliciting beneficial qualities in each
resulting system (Taylor, Medvidović and Dashofy)
32
Architectural styles vs design
patterns
• A design pattern solves a design problem
• An architectural style is not intended to solve a
problem: it is a way of organizing the structure
and behavior of a system
• Most architectural styles include some design
patterns

33
From Styles to Technology
Application
Servers

Process
Messaging
Orchestration

Architectural
Patterns/Styles
(Abstract)

Message
Object Brokers
Brokers

34
Some well-know Arc

35
Some well-know Arc

36
Some well-know Arc

37
Some well-know Arc

38
 Just Remind

Key Consideration & Key Principles

TOPIC NAME
Break: 15h:40 start
 Key Design Principles
• Separation of concerns. Divide your application into distinct features with as little overlap in
functionality as possible. The important factor is minimization of interaction points to achieve
high cohesion and low coupling. However, separating functionality at the wrong boundaries
can result in high coupling and complexity between features even though the contained
functionality within a feature does not significantly overlap.
• Single Responsibility principle. Each component or module should be responsible for only a
specific feature or functionality, or aggregation of cohesive functionality.
• Principle of Least Knowledge (also known as the Law of Demeter or LoD). A component or
object should not know about internal details of other components or objects.
• Don’t repeat yourself (DRY). You should only need to specify intent in one place. For
example, in terms of application design, specific functionality should be implemented in only
one component; the functionality should not be duplicated in any other component.
• Minimize upfront design. Only design what is necessary. In some cases, you may require
upfront comprehensive design and testing if the cost of development or a failure in the
design is very high. In other cases, especially for agile development, you can avoid big design
upfront (BDUF). If your application requirements are unclear, or if there is a possibility of the
design evolving over time, avoid making a large design effort prematurely. This principle is
sometimes known as YAGNI ("You ain’t gonna need it").

40
 Key Design Consideration
• Determine the Application Type
• Determine the Deployment Strategy
• Determine the Appropriate Technologies
• Determine the Quality Attributes
• Determine the Crosscutting Concerns

41
 Cross Cutting Concerns
• Instrumentation and logging. Instrument all of the business-critical and
system-critical events, and log sufficient details to recreate events in your
system without including sensitive information.
• Authentication. Determine how to authenticate your users and pass
authenticated identities across the layers.
• Authorization. Ensure proper authorization with appropriate granularity
within each layer, and across trust boundaries.
• Exception management. Catch exceptions at functional, logical, and
physical boundaries; and avoid revealing sensitive information to end
users.
• Communication. Choose appropriate protocols, minimize calls across the
network, and protect sensitive data passing over the network.
• Caching. Identify what should be cached, and where to cache, to improve
your application’s performance and responsiveness. Ensure that you
consider Web farm and application farm issues when designing caching.
• CI + CD + Scale + Discovery + Tracing + Resilience + Containerization

42
CAP Theory

43
 High Availability
• SPOF prevent ?

44
 Performance
• SOC
• Tech Update
• The right stack for the right workload
• Wait is blocking ! = Synchro

45
 Domain Driven Design
• Not new & quite old
• Extremly fit with Microservices
Why:
- Common languages to communicate
- Design sense that support the growth of the
system
How: Small book
Should read Bounded Context, Context Map…

46
 DDD in practice
• https://www.infoq.com/articles/ddd-in-
practice/
• Go well with BDD (Behaviours Driven
Development)
• Martin Fowler document about Domain Event
design pattern. EDA is soon in main stream
(Event Driven Architecture)
• https://www.mirkosertic.de/blog/2013/04/do
main-driven-design-example/
47
 Key Recap
• Not only Development but also Operation
• Assets : Pattern, Principle, Framework, Build vs Buy, Packaged
Application , Legacy , Framework, Mechanism
• Decomposition: Layer / Tier, Domain Driven Design
• 5 Key Design Principle
• 5 Key Design Consideration
• => Design decision is what matter (not the reference arc. , DP,
FW, package…)
• Cross-cutting handle

https://en.wikipedia.org/wiki/List_of_software_development_philosophies
https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Architecture/Design_Patterns
https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Architecture/Anti-Patterns
https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/en/
48
 Basic Architectural Styles

TOPIC NAME
 Basic Architectural Styles
• Several architectural styles have been defined
in the literature of software engineering
• They can be used as the basis for configuring
software architectures
• The basic styles which follow include:
– Pipe & Filter
– Shared-data (Repository)
– Client-Server
– Peer-To-Peer

50
 Pipe & Filter Style
Overview
• A component reads streams of data as input and
produces streams of data as output
• Suitable for applications that require a
sequence of computations to be performed on
data
• This architectural style focuses on the dynamics
(interaction) rather than the structure

51
 Pipe & Filter Style
Overview
• Filter 1 is a Source: • Filter 2 is a Sink:
– may only send data to Filter 2 – may only receive data from Filter 1
– may not receive data – may not send data

• Pipe: communication channel

• Filter: computing component

52
 Pipe & Filter Example
Batch Sequential

• A transformation subsystem or module cannot

start its process until the previous module
completes its computation 53
Pipe & Filter Example
BigData – Apache Flume

54
 Pipe & Filter and Chain of
Responsibility
• The style Pipe & Filter is inspired by the GoF
design pattern Chain of Responsibility

55
 Pipe & Filter
Pro & Cons
• Benefits:
– Filters are self containing processing services that perform a
specific function thus the style is cohesive
– Filters communicate (pass data most of the time) through
pipes only, thus the style results in low coupling
– They naturally support concurrent execution: each filter can be
implemented as a separate task and potentially executed in
parallel with other filters

• Pitfalls:
– The architecture is static (no dynamic reconfiguration)
– Filter processes which send streams of data over pipes is a
solution that fits well with heavy batch processing, but may not
do well with any kind of user-interaction
– Anything that requires quick and short error processing is still
restricted to sending data through the pipes, possibly making
it difficult to interactively react to error events
56
 Client-Server: Overview
• It has been conceived in the context of distributed systems, aiming to
solve a synchronization issue.
• The driving idea is to make unbalanced the partners’ roles within
a communication process
• One or many servers provide services to instances of subsystems,
called clients
• Each client calls on the server, which performs some service and
returns the result

• Functions performed by client:

– Requires a service through the server interface(s)
– Allows to users to communicate with the system through a certain
input (Customized user interface)
– Front-end processing of input data
• Functions performed by server:
– Centralized data management
– Services provider
– Back-end processing of the data provided by client 57
 Client-Server: Overview
• A client-server system can be logically divided into three
parts:
– The presentation tier, which is in charge of managing the
user interface (graphic events, input fields check, etc…)
– The actual application logic tier
– The data management tier for the management of
persistent data
• According to how these parts are organized, the
client-server system architecture can be:
– 2-tiered: presentation and application logic modeled as a
single tier contained in the client
– 3-tiered: one tier for each part, with dedicated servers
for application logic and data management
– n-tiered: the last two parts spread in a chain of servers
58
Client-Server: Architecture

59
 Client-Server: 2-tiers
Overview
• This style is used to describe client-server
systems where the client requests resources
and the server responds directly to the
request using its own resources
• The server does not call on another application
in order to provide part of the service
• If the server is more powerful than its clients, it
is possible to connect many clients at the same
time

60
 Client-Server: 2-tiers
Architecture
• The Application Logic may be present either at the
client side within a user interface or within the
database on the server side or spread on the both

61
 Client-Server: 3-tiers
Architecture
• Connectors:
– Remote Procedure Calls (RPC)
• Protocol: The client calls for the business logic on the
server, the business logic on the behalf of the client
accesses the database

62
Client-Server: 3-tiers
Component Diagram

63
 Client-Server: 3-tiers
Example

http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=%2Fcom.ibm.etools.struts.doc%2Ftopics%2Fcstrdoc001.html

• The browser sends a request to an Action servlet

• The Action servlet instantiates a Java bean that is connected to a database
• The Action servlet communicates with a JSP file
• The JSP file communicates with the Form bean
• The JSP file responds to the browser
64
 Client-Server: 3-tiers
Pro & Cons
• Benefits: • Pitfalls:
– High flexibility and high – The additional tier increases
modifiability: the complexity and cost of
• Components can be used in the system:
several systems • Ad hoc software libraries
• New functionalities can be have to be used to allow
added to the system by the communication among
only modifying the components
components which are in • Heavy network traffic
charge of realizing them, or
by plugging new components – Legacy software:
• Many companies make use
– More scalability and of preexisting (often
performance because we can monolithic) software systems
add as many middle tiers as to manage data
needed • Adapters have to be
– “Thin” client, because only implemented to interoperate
little communication is with the legacy software
needed between the client
and the middleware which
implements the Application
Logic
65
 Client-Server: n-tiers
Overview
• In the 3-tier applications, the middle tier is generally not a
monolithic program but is implemented as a collection of
components that are initiated by several client-initiated business
transaction
– Thus, one component can call other components to help it implement
a request
• Generally, a server can use services from other servers in order to provide its
own service
• Fundamental Items:
– User Interface (UI): a browser, a WAP mini browser, a graphical user
interface (GUI)
– Presentation logic, which defines what the UI has to show and
how to manage users’ requests
– Business logic, which manages the application business rules
– Infrastructure services:
• They provides further functionalities to the application components (
messaging, transactions support)
– Data tier:
• Application Data level
66
 Client-Server: n-tiers
Architecture
• Typical components: • Connectors:
– Client – Remote Procedure Calls (RPC)
• Same as3-tiers Architecture • Many protocols
– Web Server
• Session management
• Content creation, format and
delivery
– Application Server
• Data access objects
• Transactions
• Business logic
• Resources adapters
– Data Server
• Same as 3-tiers Architecture

67
Client-Server: n-tiers
Component Diagram

68
 Basic Architectural Styles

Peer-to-Peer style (P2P)

TOPIC NAME
P2P resource sharing
example: bitTorrent

70
Example: Skype

71
 Hybrid: Architecture
• Components:
– Peer
• An entity with capabilities similar to other entities in the system
• Each node is both a server and a client
• Autonomous: no administrative authority
• Unreliable: nodes enter and leave the network “frequently”
– Super Peer
• Gathers and stores information about peer and content available for
sharing
• Act as servers to regular peer nodes, peers to other super Peers
• Maintain indexes to some or all nodes in the system
• Connectors:
– Network protocol
• Often specialized for P2P communication
72
 Architectural styles for
interactive systems

MVC vs MVP vs PAC

TOPIC NAME
 Overview
• Motivations: dependencies of the user
interface
• The Model-View-Controller (MVC) architectural
style and its variants
• The Model-View-Presenter (MVP)
• The Presentation-Abstraction-Control (PAC)
• The architectural styles of Web applications

74
 Problems with GUI design
• User interfaces are often subject to changes in
requirements
– New types of input devices
• Touch screen, mouse, special keyboards
– New types of output
• Porting to different “look-and-feel”
• Alternative visualizations: charts, graphs, plots
• Output heterogeneity: applets, Javascript, HTML, Swing
• The user interface changes more often than
the business logic
75
Separation of the user
interface
Web applications:
 The presentation tier changes
often
 The business tier does not

Separation of the user interface:

why it is convenient?
 Market pressure
 New technologies
 Fashionable “Look and Feel”
 Modify the ‘way of working’
 E.g. Form-based to task-
based
 Extending an application
architecture
 E.g. “Webify” a rich client
application

76
 Architectural styles for
interactive systems

Application Archetypes
TOPIC NAME
 Application Type Considerations
Application type Benefits Considerations
Mobile applications Support for handheld devices. Input and navigation limitations.
Availability and ease of use for out of office users. Limited screen display area.
Support for offline and occasionally-connected scenarios.
Rich client Ability to leverage client resources. Deployment complexity; however, a
applications Better responsiveness, rich UI functionality, and improved range of installation options such as
user experience. ClickOnce, Windows Installer, and
Highly dynamic and responsive interaction. XCOPY are available.
Support for offline and occasionally connected scenarios. Challenging to version over time.
Platform specific.
Rich Internet The same rich user interface capability as rich clients. Larger application footprint on the
applications (RIA) Support for rich and streaming media and graphical display. client compared to a Web application.
Simple deployment with the same distribution capabilities Restrictions on leveraging client
(reach) as Web clients. resources compared to a rich client
Simple upgrade and version updating. application.
Cross-platform and cross-browser support. Requires deployment of a suitable
runtime framework on the client.
Service applications Loosely coupled interactions between client and server. No UI support.
Can be consumed by different and unrelated applications. Dependent on network connectivity.
Support for interoperability.
Web applications Broad reach and a standards-based UI across multiple Dependent on continual network
platforms. connectivity.
Ease of deployment and change management. Difficult to provide a rich user interface.
78
 Architectural styles for
clouds and services

TOPIC NAME
Software-as-a-Service (SaaS)
• Definition of SaaS: Internet-based deployment (for access and
management) of commercially available software
• Service managed from “central” locations enabling customers
to access applications remotely via web
• Delivery: one-to-many model (single instance, multi-tenant
architecture) including architecture, pricing, partnering, and
management characteristics
• Centralized updating, which obviates the need for end-users to
download patches and upgrades
• Frequent integration into a larger network of communicating
software—either as part of a mashup or a plugin to a platform
as a service

80
 Software as a service
• An operating system service?
– Program execution, file management

• A Software Service?
– Messaging Service
– Log Service
– Peer to peer distribution
– Search engine

• A Business Service?
– Customer service
– Bidding service
81
 Software services: a
multidisciplinary problem

82
 Dimensions of Sw
Engineering for Services

83
 SOC and SOA
• Service Oriented Computing is a distributed
programming paradigm for business
applications supporting complex enterprises

• Service Oriented Architectures are systems of

services producers and service consumers

• Mostly made of independent software systems

able to be dynamically integrated
84
 SOA
• SOA = Service Oriented Architecture
• SOA is a recent term, but in the past have been
built many systems that today we could call
SOAs. Example: the Web
• The essence of a SOA lies in independent
services interconnected by messages
• On the Web, a specific SOA technology is Web
Services (W3C)

85
SOA

86
OMG Standards for SOA

87
 Typical topics in SOA
• Model, design, and implement a SOA
• Create an agile, reusable SOA
• Automate business processes by mapping to
the architectural model
• Orchestrate services and execute processes
with the Business Process Execution Language
(BPEL)
• Achieve interoperability within a SOA using
proven standards and best practices
• Secure and govern an enterprise SOA
88
SOA Meta Model

89
Standardizing bodies for SOAs
• W3C (1994)
• OASIS (1993), consortium of former GML
providers, deals with applications using XML
• OMG (1989)
• WS-I (2002), promotes interoperability among
the stack of Web Services specifications"

90
 Elements of SOA Design
• Business Modeling
• Service Oriented Architectural Modeling and
Design
• Model Driven assumptions (loose coupling)
• Distributed objects and MOM (Message
Oriented Middleware) for component-based
sw systems

91
 Services and SOAs
• A service is a program interacting via message
exchanges
– On Web all messages and service descriptions are
written in XML
• A SOA is a set of deployed services cooperating
in a given task
– Adapt to new services after deployment

92
SOA Reference Architecture

93
Main SOA Standards

94
Oracle Fusion Middleware
SOA Suite

95
TIBCO SOA Suite

96
WSO2 SOA Suite

97
JBOSS SOA Suite

98
 Integration is important
• API with REST(ful) style
- REpresentational State Transfer
• The six constraints are:
– Uniform Interface
– Stateless
– Cacheable
– Client-Server
– Layered System
– Code on Demand (optional)

99
 Integration is important
• API is great but…

Request/Response style is not the only way

Many scenarios demand different integration
mechanisms (msg queue, topic,…)

100
 Integration is important
• API is great but…

Point 2 Point Integration is a mess

101
P2P APIs

102
API-led Integration

103
API Led

104
 Integration is important
• API Gateway is now high-demand
• Many design consideration to think about

105
 Integration is important
• Try yourself API Gateway
• Explore integration plats/mechanisms:
– Mulesoft
– WSO2 microIntegrator
– https://ballerina.io/learn/

106
Lucky ? Unlucky ?

TECHNOLOGY UPDATED !

FRAMEWORK BETTER & BETTER

COMPUTE CHEAPER & CHEAPER

PROBLEM BIGGER & BIGGER

107
 Architectural styles for
clouds and services

TOPIC NAME
 Why Cloud ?
• TCO -> cloud movement
• Faster way of doing thing on/with cloud
Scalable with cost effective:
- Vertical scale
- Horizontal scale

109
 Think Cloud
• HA - High Availability
 Think Cloud
• DR – Disaster Recovery

• Hard thing: Fallback after Failover

 Think Cloud
• Amazing Services : think of those common
problem (storage, mass ingestion, api
management, security, key-vault, cache,
queue, topic,….)

• Any one don’t know S3 ? Google Cloud

Storage ? Azure Storage Account ?
 Let do simple math

I share 100 GB
of movies to
10 friends
in 1 month
 Think Cloud
• Cost factor that impact our architect decide

• Scale always bring challenges to our solution

even the vendor do a lot of magic thing

• Werner Vogels quote

 Where to start ?
https://aws.amazon.com/builders-library

https://docs.microsoft.com/en-
us/azure/architecture/best-practices/index-
best-practices

https://docs.microsoft.com/en-
us/azure/architecture/browse/?products=azure
&azure_categories=web
The shift of focus

• Performance
• Scale

• Reliability
• Latency
 Cloud Solution Architect
Pattern Pattern Pattern
Ambassador CQRS Materialized View
Anti-Corruption Layer Deployment Stamps Pipes and Filters
Asynchronous Request-Reply Event Sourcing Priority Queue
Backends for Frontends External Configuration Store Publisher/Subscriber
Bulkhead Federated Identity Queue-Based Load Leveling
Cache-Aside Gatekeeper Retry
Choreography Gateway Aggregation Scheduler Agent Supervisor
Circuit Breaker Gateway Offloading Sequential Convoy
Claim Check Gateway Routing Sharding
Compensating Transaction Geodes Sidecar
Competing Consumers Health Endpoint Monitoring Static Content Hosting
Compute Resource Consolidation Index Table Strangler Fig
Leader Election Throttling
Valet Key
 Final Exam
• TBD
• Open & Closed