COMP2511 Week 9

Agenda

  • Admin Stuff
  • Architectural Characteristics
  • Architectural Styles

Admin Stuff

  • Assignment 2 is due next Wednesday at 3pm
  • Late penalty is standard 5% per day reduction of on-time assignment mark (calculated per hour to next hour) 
  • 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

Assignment 1

  • Assignment 1 marks have been released! 

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

What is the difference between Microservices and Event-Driven Architecture? 

Microservices and Event-Driven can often appear together, but are different conceptually. 

  • Microservices is about how you structure your system into small, independent services
  • Event-driven is about how services communicate and react to each other

 

Event-driven systems usually use microservices but not all microservices uses event-driven communication (i.e. have microservices talk sync through HTTP APIs)

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

Case Study: How Requirements Shape Architecture

Architectural requirements drive changes all the time. GitLab and Atlassian (Confluence) both started as monoliths, but their goals were different.

 

This led them down different paths.

Gitlab

Context:
GitLab engineers found that their large Rails monolith slowed development and created tight coupling between teams.
Instead of moving immediately to microservices, they implemented a modular monolith.

Key drivers:

  • Improve development velocity and predictability

  • Reduce coupling and improve maintainability

  • Allow teams to work independently

Architectural characteristics:
Maintainability, Modifiability, Deployability

Atlassian

Context:
Atlassian rearchitected Confluence Cloud to address global scale and reliability requirements.
They gradually decomposed the monolith into independent services, allowing teams to deploy and scale autonomously.

Key drivers:

  • Handle multi-tenant workloads globally

  • Improve reliability and uptime

  • Enable faster delivery through team autonomy

Architectural characteristics:

Scalability, Availability, Reliability, Team Autonomy

GitLab's Goals

Atlassian's Goals

  1. Boost development speed and predictability
  2. Improve code quality and reduce coupling
  3. Enable independent deployment of components

 

Key qualities: maintainability, modifiability, deployability

 

Source: Gitlab's ADR

  1. Scale globally
  2. Improve performance
  3. Ensure resilience
  4. Give teams autonomy

 

Key qualities: scalability, performance, reliability, team autonomy

 

Source: Atlassian's Engineering Blog

 

Solution​

GitLab

Monolith → Modular Monolith

Atlassian

Monolith → Microservices, Stateless

  1.  Keeps one app but organizes code into clear modules
  2. Reduces coupling, adds useful abstractions
  3. Lets parts of the app be deployed separately if needed
  1. Made the app stateless and multi-tenant for global scale
  2. Gradually split into microservices for resilience & team autonomy
  3. Routing layer allows smooth migration without breaking anything

Both took different paths, because they wanted to solve different problems.

Compare and Contrast

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