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.

 

  1. Identify architectural characteristics

    • Also consider some of the business drivers that reveal critical characteristics

  2. Discuss which architecture could work best and worst

  3. 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?

Made with Slides.com