COMP2511 Week 9
Agenda
- Admin Stuff
- Architectural Characteristics
- Architectural Styles
Admin Stuff
- Assignment 2 is due next Friday at 3pm
- A reminder that no late submissions are accepted for this assignment under any circumstances
- Again, please make sure your merge requests are linked in your blogs under the relevant tasks, so it is easy for me to give you marks :)
Assignment 2
Admin Stuff
Sample Exam
- Reminder that there will be a in-person exam environment sample exam in Week 10.
- It will provide you with an opportunity to look at some past questions to observe the types of the questions present in the final exam (the number and the difficulty of the questions may differ).
Architectural Characteristics
Imagine you’ve built a perfect online banking app. Every feature works flawlessly.
BUT then when 100 users log in, the system crashes. Did you succeed?
Success in building software isn't just about getting the features to work.
It's about designing a system that performs well under expected conditions
What makes software good?
Architectural Characteristics
- Influence critical design decisions structure, behaviour, and trade-offs in software design
- Impacts the system's long-term success, not just initial delivery
Architectural characteristics, also known as non-functional requirements, define fundamental qualities software architecture must support.
Architectural Characteristics
| Characteristic | Description | Example |
|---|---|---|
| Performance | How fast system responds under given load | Page loads in under 2 sec for 1000 users |
| Scalability | Ability to handle increased workload (users, data) | Ticketing sales for a popular band |
| Availability | Percentage of time the system is operational | "Five nines" (99.999%) uptime |
| Reliability | Ability to run consistently without errors | Banking system that never loses a transaction |
| Security | Protection against threats, unauthorised access | OAuth 2.0 authentication |
| Maintainability | Ease of making changes, fixing bugs or adding new features | Modular codebase with clear separation of concerns |
| Testability | How easily the system can be tested | Unit tests can be run in isolation |
| Extensibility | Ability to add new functionality with minimal changes | VSCode extensions |
| Deployability | How easy is it to deploy the software | Microservice-based e-commerce website |
Here are some examples of characteristics, not an exhaustive list:
Architectural Styles
Architectural Styles
Architectural styles are predefined patterns and philosophies guiding how software systems are structured and deployed.
- Each style comes with trade-offs in scalability, performance, complexity, etc.
- Choosing the right style is a core part of software architecture. Shapes how the system behaves and evolves
Categories of Architectural Styles
Partitioning
Code organised by technical layers vs. domain roles
e.g. For e-commerce platform teams can be separated in
- Technical: Frontend, backend, DevOps/Infra teams
- Functional: Customer, Inventory, Payment
Deployment
- Monolithic
- Components packaged and deployed as a single unit (usually one codebase)
- Distributed
- System broken into independent deployable services that communicate over a network
We are the architect team designing a food delivery app and it is up to us to decide the architecture style.
Layered
Definition: Organises each distinct technical responsibilities into separate layers
- Domain logic spans multiple layers
-
Presentation (UI components)
-
Workflow (business logic components)
-
Persistence (database schemas and operations)
-
- Easy to understand and lets you build simple systems fast
Layered
Example of Layered:
OSI Model which describe the networking system's communication functions
(think IP addresses!)
Modular Monolithic
Definition: Deployed as a single unit and organised in domain-based modular structure
- Each domain is represented as a module
- Shared database
- Different parts of the app communicate through public controller interfaces
What it looks like as code!
Modular Monolithic
Example of Modular Monolithic:
Shopify started as monolithic Rails app but later modularised
Microservice
Definition: Single-purpose, separately deployed units for environments requiring frequent changes and scalability
- A microservice performs one specific function very well and communicates with other microservices over a network
- Each service own their own data. Direct access to data is restricted to the owning microservice
- Balance of granularity disintegrators (smaller services) and integrators (larger services)
Microservices
Example of Microservices:
Amazon, Netflix and Uber famously uses microservices
Give one real-world scenario where Microservices would be a poor choice. Explain why.
Microservices
If we had started with microservices in the early stage (Small team, simple requirements), that would’ve been a mistake:
- Adds unnecessary complexity (tooling, ops, communication)
- Higher operational cost: infra, monitoring, deployment
- Slower development at first due to over-engineering
- Monolith is simpler, cheaper, easier to manage for such cases
→ Microservices are great for scale, but not for MVPs or small teams
When Microservices would be a poor choice. Explain why.
Microservices
- It allows internal separation of concerns, easier to refactor, and makes future migration to microservices much smoother since modules map cleanly to future services
-
It is less complex: single deployment, fewer moving parts
-
Skill growth, lets teams adopt microservice thinking gradually
-
Cost effective, avoids early microservice overhead
Why might a team choose a Modular Monolith as an intermediate step before adopting Microservices?
So instead, many teams go for a Modular Monolithic: a structures monolithic codebase with clear boundaries between modules like orders, payments, and users
Event-Driven
Definition: Structures systems to respond to events, which are significant changes in a system state.
- Components in a system communicate faster by producing and responding to events asynchronously
- Events broadcast something that has already happened across the entire system and do not have responses (async)
- EDA can choose between monolithic, domain-partitioned or database-per-service databases
Event-Driven
Example of Event-Driven:
AT&T for event ticketing
Event-Driven
What are the potential risks of using an Event-Driven architecture in a mission-critical system?
-
Eventual consistency: data takes time to sync → fine for notifications, but bad for instant consistency needs
-
Error handling: hard to trace bugs → when something breaks, it’s tough to figure out where. Errors can quietly get lost.
-
Operational overhead: Complex deployment & monitoring
-
Event Storms & Failures: Overloaded queues, poison messages
-
Governance Gaps: Schema mismatches, data duplication
Which architectural pattern would you choose for a system requiring strong consistency across components? Justify your choice.
Monolithic or Layered (single deployment). Because:
- Centralized DB = strong consistency
- Supports ACID transactions
- Simpler to manage integrity (e.g., financial systems)
Why not others:
- Microservices: need complex distributed coordination
- Event-Driven: async & eventual consistency by nature
Designing Your Own Architecture
Design the architecture for an online ticketing system.
-
Identify architectural characteristics
-
Also consider some of the business drivers that reveal critical characteristics
-
-
Discuss which architecture could work best and worst
-
List some tradeoffs they would make designing the architecture and why
Discussion Points
Is it better to optimise early for scalability or wait until it becomes a problem?
Can a modular monolith achieve the same team autonomy as microservices?
Are there systems where event-driven architecture causes more harm than good?
Should every modern application aim to use Microservices?
How do you decide whether to prioritise maintainability or performance in an architecture?
COMP2511 Tute09
By rebeccahsu
