This document outlines a session on software architecture fundamentals, covering key concepts, patterns, tools, and components. It highlights the differences between monolithic and microservice architectures, their respective advantages and disadvantages, and provides recommendations for further reading and analysis. Additionally, the agenda includes interactive activities to engage participants in understanding their current knowledge in software architecture.

1. Software architecture fundamentals
Session #10
Delivery Management School

2. 2
Agenda
Let’s get to know each other
01
What is software architecture
02
Software architecture patterns
03
Tools and components
04
Monolith vs. microservice architecture
05
Recommendations
06

3. 01 Let’s get to know each other

4. Where you are towards software architecture?
Join at menti.com
Use code 2587 0856
5

5. My goal for today
Give an overview of software architecture
practices, tools, basic software architecture
concepts.
6

6. 02 What is software architecture

7. So, what is software architecture?
A HIGH-LEVEL ABSTRACT VIEW
OF A SOFTWARE SYSTEM
8

8. Why?
SOFTWARE ARCHITECTURE MAKES
FUNDAMENTAL STRUCTURAL CHOICES THAT
ARE COSTLY TO CHANGE ONCE IMPLEMENTED
9

9. What software architect does?
SOFTWARE ARCHITECT TRANSLATES BUSINESS
REQUIREMENTS INTO TECHNICAL SOLUTIONS
WHICH MEET THE BUSINESS NEEDS
10

10. 11
Scalability &
performance
Fit for purpose Maintainability,
adaptability
Reliability & Fault
Tolerance
Security
11
What good software architecture solves
Cost efficiency

11. What about system design?
12
SOFTWARE
ARCHITECTURE
SYSTEM
DESIGN

12. Software architecture
13

13. System design
14

14. 15
TOGAF
TOGAF (The Open Group
Architecture Framework) is a
framework and methodology for
enterprise architecture that
provides an approach for
designing, planning,
implementing, and governing an
enterprise information
technology architecture

15. 03 Software architecture patterns

16. 17
1. Client-server layered (2, 3, n-tier) architecture
Organizes the system into layers, each with specific
responsibilities.
Example:
Online banking systems use layered architecture to
separate the user interface, business logic, and data
access.

17. 18
2. Model-View-Controller (MVC) architecture
Divides an application into three
interconnected components: Model
(data), View (UI), and Controller
(business logic).
Example:
Most of the web frameworks, like
Django or Ruby on Rails are built on
MVC to separate concerns and
improve maintainability.

18. 19
3. Event-driven architecture
Components communicate through events, which trigger actions in other components.
Example:
E-commerce platforms like Amazon use event-driven architecture to handle user actions such as purchases
and inventory updates.

19. 20
4. Event sourcing architecture
An append-only store to record
the full series of actions taken
on data a sequence of events
instead of the current state.
Example:
Many financial and e-commerce
systems use event sourcing to
maintain a complete history of
transactions.

20. 21
5. Monolithic architecture
Is built as a single, indivisible unit where all
components are tightly coupled and run as
a single process.
Example:
LinkedIn initially started with a monolithic
architecture known as ‘Leo.’ This
architecture included all the functionalities
such as user profiles, connections,
messaging, and job postings within a
single codebase.

21. 22
6. Microservice architecture
Breaks down an application into
small, independent services that
communicate over a network.
Example:
Netflix uses microservices to
manage various functionalities
like user authentication and
content streaming.

22. 23
7. Microkernel architecture
A system design where the core
functionality is minimal, handling
only essential services like
communication between hardware
and software, while other services
run in user space.
Example:
Systems requiring high modularity
and reliability, such as embedded
systems, real-time operating
systems, and some server
environments.

23. 24
8. Command Query Responsibility Segregation (CQRS)
Separates the read and write
operations of a system into different
models and streams.
Example:
Online stores use CQRS to handle
commands (e.g., placing orders)
separately from queries (e.g.,
viewing product catalogs).

24. 25
9. Peer-to-peer architecture
Each node in the network acts as
both a client and a server, sharing
resources directly with other nodes.
Example:
BitTorrent is a peer-to-peer file-
sharing protocol where each
participant can upload and
download files.

25. 04 Tools and components

26. 27
Enterprise apps Startup, rapid
prototyping
“Old but gold”
Modern & sexy Embedded &
gaming
27
Languages: server and system
AI & Data science

27. 28
Enterprise Universal & popular Fast & lightweight
iOS Android
28
Front-end and mobile
Cross-platform

28. 29
High availability principle
High availability is a
system's ability to
remain operational
and accessible for a
high percentage of
time, minimizing
downtime and
ensuring continuous
service.

29. Scaling Strategies
Vertical Scaling (Scale-up)
Involves adding more resources, such
as CPU, RAM, or storage, to an
existing server to handle increased
load.
Mainly for applications with
predictable growth where upgrading
hardware can improve performance.
Horizontal Scaling (Scale-out)
Involves adding more servers to
distribute the load and manage larger
datasets and higher traffic.
Ideal for applications with high and
unpredictable growth, allowing for
better load distribution and fault
tolerance.
30

30. Load Balancing & Autoscaling
Load balancing
Load balancing distributes incoming traffic across
multiple servers to ensure no single server becomes
overwhelmed.
Essential for applications with high availability
requirements, for continuity even if some servers
fail.
Auto scaling
Auto scaling automatically adjusts the number of
servers based on the current load and demand,
ensuring optimal performance and cost-efficiency.
Ideal for applications with variable workloads, where
the number of users can fluctuate significantly.
31

31. Synchronous vs. Asynchronous
Synchronous
Tasks are executed one after another, blocking the
execution of subsequent tasks until the current one
completes.
Suitable for simple, linear tasks where operations
depend on the completion of previous ones, such as
reading a file line by line.
Asynchronous
Tasks can be initiated and run in the background,
allowing the program to continue executing other
tasks.
Ideal for tasks that involve waiting, such as I/O
operations, network requests, or user interactions,
where non-blocking behavior improves efficiency and
user experience.
32

32. 33
Databases
Relational databases (RDBSM) - store data in tables with rows and columns. They use SQL for defining and
manipulating data.
Use Case: Ideal for applications with well defined data structure, requiring complex queries and transactions
(ACID - Atomicity, Consistency, Isolation, Durability), such as financial systems and enterprise applications.

33. 34
Databases
NoSQL Databases - Designed for unstructured data and flexible schemas. They can handle large volumes of
data and are optimized for specific data models.
Use Case: Suitable for big data applications, real-time web apps, and systems requiring high scalability and
flexibility.

34. 35
Horizontal &
Vertical Scaling
Sharding Replication
Indexing Caching
35
Database Scaling Strategies
Different type of DB

35. 36
Server-side Caching
Server-side caching – Very fast (sub-millisecond) in-memory database, commonly used for caching the main
database query results, repetitive queries, session management.
Use Case: High performance, high load web applications, real-time analytics.

36. 37
Content Delivery Network (CDN)
CDN is a group of geographically distributed servers that cache and deliver web content to users from the
nearest server, reducing latency, amount of server and database requests and improving load times.
Use Case: CDNs are commonly used to accelerate the delivery of static assets like images, videos, and static
HTML pages for websites, ensuring a faster and more reliable user experience.

37. 38
Message queue / message brokers
Message queues / brokers facilitate communication between services by receiving, storing, and forwarding
messages, ensuring that producers and consumers can operate independently and asynchronously.
Use Case: Commonly used in microservices architectures to decouple services, handle long-running tasks,
and ensure reliable message delivery, such as processing orders in an e-commerce system.

38. 39
Big Data
Big Data refers to
extremely large (TB, PB)
and complex datasets
that require advanced
tools and techniques for
storage, processing, and
analysis to extract
meaningful insights.

39. 40
AI: Tools

40. 41
AI: Architecture
AI era spawns a group
of new tools and
frameworks to build AI-
powered applications.

41. 05 Monolith vs. microservice architecture

42. Monolith vs. Microservices
A single, unified codebase where all components
are interconnected and interdependent.
A collection of small, independent services that communicate
over APIs, each handling a specific business function.
43

43. Monolith: Pro’s and Con’s
Advantages
Simplicity: Easier to develop, test, and deploy
initially.
Performance: Direct calls within a single process
can be faster than inter-service communication.
Disadvantages
Complexity: As the application grows, it becomes
harder to manage and understand.
Scalability: Scaling requires scaling the entire
application, not just parts of it.
Deployment: Any change requires redeploying the
entire application.
Cost of change: With application growing, it becomes
increasingly difficult to do changes and updates.
44

44. Microservices: Pro’s and Con’s
Advantages
Scalability: Individual services can be scaled
independently.
Flexibility: Different technologies and languages
can be used for different services.
Resilience: Failure in one service doesn't necessarily
bring down the entire system.
Disadvantages
Complexity: More complex to develop and manage.
Communication Overhead: Inter-service
communication can introduce latency and require
robust network management.
Data Management: Ensuring data consistency
across services can be challenging.
45

45. Use Cases
Monolith
Small to Medium Applications: Suitable for simpler,
smaller applications with limited scalability needs.
Tightly Coupled Systems: Where components are
highly interdependent and frequent communication
is required.
Microservices
Large-Scale Applications: Ideal for complex, large-
scale applications requiring high scalability and
flexibility.
Continuous Deployment: Environments where
frequent updates and deployments are necessary.
46

46. 47
Steps to convert monolith into microservices
Identify domains
Determine the
different business
domains within the
monolith
Develop independent
services for each
domain
Implement an API
gateway to manage
communication
between services
Ensure each service
has its own database
or data storage
Gradually migrate
functionalities from
the monolith to
microservices
Create services API gateway Data management Incremental migration

47. 05 Recommendations

48. 49
To read
Software architecture in
practice
Will give you a good
foundation and should
cover most of the
questions in software
architecture a manager
should know.

49. 50
To watch
Software Architecture
& Design of Modern
Large Scale Systems
by Michael Pogrebinsky

50. 51
To listen to
Experienced developers
in your team

51. Questions
THANK YOU!

52. Hometask

53. Hometask
1. Analyze the project you work on. Create an
architecture diagram of how it is built now.
2. Propose architecture improvements
54