Unit 5.1 · Tutorial 1

Architectural Design Principles

Chapter 12 · System Design & Deployment
~2.5 hours Intermediate Monolith · Microservices · Serverless · C4

Overview

Software architecture is the foundation of any successful system. This tutorial covers the major architectural styles: monolithic, microservices, and serverless, along with the C4 model for visualising architectures. You'll learn to evaluate trade‑offs and make informed decisions based on project requirements.

Why this matters: The architecture you choose has long‑term implications for development speed, scalability, maintainability, and team structure. A well‑chosen architecture makes your system easier to evolve and operate.

1. Architectural Styles

An architectural style defines the high‑level structure and organisation of a software system. Key styles include:

  • Monolithic: Single deployable unit.
  • Microservices: Suite of independently deployable services.
  • Serverless: Event‑driven, managed by cloud providers.
  • Event‑driven: Asynchronous communication via events.
  • Layered (n‑tier): Presentation, business, and data layers.
// Simple comparison | Style | Deployment | Team Scaling | Complexity | |--------------|------------|--------------|------------| | Monolith | Single | Low | Low | | Microservices| Multiple | High | High | | Serverless | Individual | Very High | Medium |

2. Monolithic Architecture

A monolithic application is built as a single, indivisible unit. All components are packaged together and deployed as one.

Advantages

  • Simpler development (one codebase, one deployment).
  • Easier debugging and testing (everything is in one place).
  • Lower operational overhead.

Disadvantages

  • Scaling bottlenecks (everything scales together).
  • Team coordination overhead (multiple teams on one codebase).
  • Technology lock‑in (hard to change languages/frameworks).
  • Slow deployment cycles (must deploy the whole thing).
// Example: A monolithic e‑commerce app ┌─────────────────────────────────────────┐ │ Monolithic App │ │ ┌───────────────────────────────────┐ │ │ │ Web UI (HTML/CSS/JS) │ │ │ ├───────────────────────────────────┤ │ │ │ Business Logic (Order, Product) │ │ │ ├───────────────────────────────────┤ │ │ │ Data Access (ORM) │ │ │ ├───────────────────────────────────┤ │ │ │ Database (PostgreSQL) │ │ │ └───────────────────────────────────┘ │ └─────────────────────────────────────────┘
When to choose a monolith: Small teams, simple applications, startups in early stages, or when you need to move quickly with minimal complexity.

3. Microservices

Microservices decompose the application into small, independent services that communicate via APIs (REST, gRPC, messaging).

Advantages

  • Independent deployment and scaling.
  • Technology diversity (each service can use its own stack).
  • Team autonomy (small teams own services).
  • Fault isolation (one failure doesn't bring down the whole system).

Disadvantages

  • Distributed system complexity (network latency, retries, timeouts).
  • Data consistency (distributed transactions, eventual consistency).
  • Operational overhead (deployment, monitoring, logging).
  • Testing complexity (integration tests, contract testing).
// Example: Microservices for e‑commerce ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Order │ │ Product │ │ User │ │ Service │──▶│ Service │──▶│ Service │ └──────────┘ └──────────┘ └──────────┘ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Order │ │ Product │ │ User │ │ DB │ │ DB │ │ DB │ └──────────┘ └──────────┘ └──────────┘
When to choose microservices: Large teams, complex domains, need for independent scaling, or when you have strong DevOps capabilities.

4. Serverless Architecture

Serverless (Function as a Service) allows you to run code without managing servers. Cloud providers handle scaling, availability, and maintenance.

Advantages

  • Zero server management.
  • Auto‑scaling (from 0 to thousands of concurrent requests).
  • Pay‑per‑use pricing (only pay for execution time).
  • Fast development (focus on business logic).

Disadvantages

  • Cold start latency.
  • Vendor lock‑in (AWS Lambda, Azure Functions, etc.).
  • Execution limits (timeout, memory).
  • Debugging and monitoring challenges.
// AWS Lambda function (Node.js) exports.handler = async (event) => { // event contains the input const name = event.name || 'World'; return { statusCode: 200, body: JSON.stringify({ message: `Hello, ${name}!` }), }; }; // Deploy with AWS SAM or Serverless Framework.

5. C4 Model for Diagrams

The C4 model is a simple, standardised way to visualise software architecture at different levels of abstraction.

  • Level 1: System Context – The system and its users/actors.
  • Level 2: Containers – Applications, databases, message queues.
  • Level 3: Components – Internal building blocks of a container.
  • Level 4: Code – Class diagrams (optional).
// Example C4 Level 2 (Containers) for e‑commerce ┌───────────────┐ ┌───────────────┐ │ React SPA │───▶│ Node.js API │ │ (Frontend) │ │ (Backend) │ └───────────────┘ └───────┬───────┘ │ ┌─────▼─────┐ │PostgreSQL │ │ Database │ └───────────┘
Tools: Use draw.io, Lucidchart, or Structurizr for creating C4 diagrams.

6. Trade-offs & Decision Making

No architecture is perfect for every situation. Consider these factors:

  • Team size and structure: Small teams → monolith, large teams → microservices.
  • Development speed: Monoliths are faster to start, microservices are faster to scale teams.
  • Scalability: Microservices scale more granularly.
  • Operational complexity: Monoliths are simpler to operate.
  • Technology evolution: Microservices allow incremental technology upgrades.
// Decision matrix // Score each style from 1-5 for each criterion | Criterion | Monolith | Microservices | Serverless | |-----------------|----------|---------------|------------| | Simplicity | 5 | 2 | 3 | | Scalability | 2 | 5 | 5 | | Team autonomy | 2 | 5 | 4 | | Cost | 3 | 2 | 4 | | Operational | 4 | 2 | 4 | // Weighted decision.

Quiz

Question 1

Which architectural style uses independently deployable services that communicate via APIs?

  • Monolithic
  • Microservices
  • Serverless
  • Layered
Show answer
B. Microservices.

Question 2

What is the primary disadvantage of a monolithic architecture?

  • High complexity
  • Scaling bottlenecks
  • Vendor lock‑in
  • Cold start latency
Show answer
B. Scaling bottlenecks.

Question 3

Which level of the C4 model shows the high‑level system interactions with users and external systems?

  • Level 1: System Context
  • Level 2: Containers
  • Level 3: Components
  • Level 4: Code
Show answer
A. Level 1: System Context.

Exercises

Exercise 1

List 3 advantages and 3 disadvantages of microservices compared to a monolith.

Sample answer

Advantages: Independent scaling, technology diversity, team autonomy.

Disadvantages: Distributed system complexity, data consistency issues, operational overhead.

Exercise 2

Draw a Level 2 (Containers) C4 diagram for a simple blog platform with a React frontend, a Node.js API, and a PostgreSQL database.

Sample answer
[React App] ---> [Node.js API] ---> [PostgreSQL DB] (Browser) (Backend) (Data Store)

Include arrows showing HTTP communication between React and API, and API to database.

Homework

Homework 1

For your capstone project, identify which architectural style you are using and why. Write a 300‑word justification, considering team size, scalability needs, and complexity.

Sample outline
  • Style: e.g., Microservices (if you split into multiple services) or Monolith (if a single application).
  • Justification: Discuss team size, future scalability, technology choices, and trade‑offs.

Mini‑Project

Architecture Decision Document

Write an Architecture Decision Record (ADR) for your capstone project's architecture style. Include:

  • Context: Project goals, constraints
  • Decision: Which architectural style you choose
  • Rationale: Why this style fits
  • Consequences: What trade‑offs you accept
Sample ADR

ADR 001: Choose Monolith for Capstone

Context: We are building a task management app with a team of 3 developers. We need to move fast and iterate quickly.

Decision: We will build a monolithic application using React + Node.js + PostgreSQL.

Rationale: Simpler development, easier testing, and faster deployment cycles. The team is small, so a monolith reduces coordination overhead.

Consequences: Scaling will be vertical initially. If needed, we can extract services later.

Tutorial Summary

You learned the major architectural styles (monolith, microservices, serverless), the C4 model for visualising architectures, and the trade‑offs involved in making architectural decisions. This foundation will help you design systems that meet your project's needs.

Key takeaway: No architecture is one‑size‑fits‑all. Evaluate your project's context and make a conscious, justified choice.