Admin Stuff

• Assignment 2 is due next wednesday at 3pm (19th November 2025)
• 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?

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 Quiz

https://www.educaplay.com/learning-resources/26531280-cloud_system_qualities_match.html

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

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:

Gitlab 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:

Confluence, Amazon, Netflix and Uber famously use microservices

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'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

Atlassian's Goals

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

GitLab → Modular Monolith

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

Atlassian → Stateless Monolith → Microservices

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

The solution?

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

Gitlab Architecture

• Bullet One
• Bullet Two
• Bullet Three

Source

Confluence's Architecture

• Bullet One
• Bullet Two
• Bullet Three

Intermediate between Monolith and Microservices

Compare and Contrast

Uber's Architecture (simplified)

• Bullet One
• Bullet Two
• Bullet Three

Give one real-world scenario where Microservices would be a poor choice. Explain why.

Microservices

 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?

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

Case Study: Netflix's Notification Dilemma

• You’re an engineer at Netflix.
   
• Over 220 million members are doing everything at once: updating profiles, changing plans, adding shows to ‘My List,’ or streaming the latest hit.
   
• How do you ensure every device shows the right information in real-time?

Why Netflix needed real time notifications?

• Here are some real use-cases Netflix engineers wrote about in their engineering blog:
   

Key Requirements

• Updates must appear instantly across phones, TVs, tablets, and web.
• Millions of events per second at peak times.
• Devices are online/offline and very varied.
• Some events are critical (profile changes), others are less urgent (diagnostics).

Architectural Goals/Characteristics

• Real-time updates & consistency across devices
• High throughput & scalability
• Event prioritization
• Support for multiple platforms & device types
• Flexibility to add new features easily
• Resilience to failures
• Observability for monitoring and debugging

All of this necessitated a new way to think about communication. Enter Event-Driven Architecture.

Event-Driven Architecture (EDA) to the Rescue

• Single event source: All actions flow through a unified system (Manhattan).
• Asynchronous & scalable: Events go into priority-based queues and are processed by dedicated clusters.
• Push + Pull model: Ensures updates reach online and offline devices.
• Targeted delivery: Only notify devices that need it, reducing traffic.
• Plug-and-play: New events/features can be added quickly.
• Reliable & observable: Less coupling, bulk-headed delivery, and real-time monitoring keep the system healthy.

Netflix's

RENO

Architecture

Event-Driven

What are the potential risks of using an Event-Driven architecture in a mission-critical system?

Which architectural pattern would you choose for a system requiring strong consistency across components? Justify your choice.

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?