LearningTree
Software Architecture Overview
What is software architecture? Why does it matter? How do architects think about structure, trade-offs, quality, and evolution? A concise overview — with links to deep dives.
01
Chapter One · Introduction
What Is Software Architecture?
Software architecture is the set of significant design decisions about the organisation of a software system — the major components, their relationships, and the principles guiding their design and evolution.
Structure
- Decomposition into components, modules, and services
- Responsibilities assigned to each building block
- Interfaces that define how blocks communicate
Trade-offs
- Every decision involves trade-offs
- Consistency vs. availability
- Simplicity vs. flexibility
- Performance vs. maintainability
Communication
- How components interact — sync (REST, gRPC) vs. async (events, queues)
- Protocols, contracts, and data formats
Evolution
- Good architecture accommodates change
- Systems are never "done" — they evolve with requirements
The Role of a Software Architect
The Architect's Core Responsibilities
📋 Chapter 1 — Summary
- Architecture = structure + trade-offs + communication + evolution
- The architect is a collaborative technical leader — not an ivory-tower decision-maker
- Every decision is a trade-off — document the rationale, not just the choice
02
Chapter Two · Architectural Styles
Architecture Styles & Patterns
An architectural style defines the overall shape of a system. Patterns solve specific recurring problems within that shape. Most real systems combine multiple styles and patterns.
Monolithic
- Single deployable unit
- Simple to develop, test & deploy
- Best for small teams & MVPs
- Scaling requires scaling the whole app
Microservices
- Small, independently deployable services
- Each owns its own data & business logic
- Independent scaling & team autonomy
- Distributed system complexity
Event-Driven
- Components communicate via events
- Loose coupling, high scalability
- Event Sourcing & CQRS
- Eventual consistency challenges
Layered / N-Tier
- Presentation → Business → Data
- Each layer depends only on layer below
- Well-understood, good for CRUD
- Can lead to tight inter-layer coupling
Serverless
- Code runs in response to events (Lambda)
- Zero server management, auto-scaling
- Pay-per-execution model
- Cold starts & vendor lock-in
Pipes & Filters
- Data flows through a sequence of filters
- Each filter transforms data independently
- Great for ETL & data processing
- Composable & reusable
Monolith → Microservices: When to Choose What
📋 Chapter 2 — Summary
- Monolith: Start here — simple, low overhead, good for small teams
- Microservices: Independent deployment & scaling — but adds distributed system complexity
- Event-Driven: Loose coupling via events — eventual consistency trade-off
- Layered: Well-understood separation of concerns — prone to cascade coupling
- Most real systems combine multiple styles and patterns
03
Chapter Three · Design Principles
Core Design Principles
These principles guide good software design across all architectural styles — from monoliths to microservices, from classes to services.
SOLID Principles
S — Single Responsibility
A class should have only one reason to change. Separate concerns into focused units.
O — Open/Closed
Open for extension, closed for modification. Add behaviour via new classes, not changing existing code.
L — Liskov Substitution
Subtypes must be substitutable for their base types without altering correctness.
I — Interface Segregation
Prefer many specific interfaces over one general-purpose interface. Clients shouldn't depend on methods they don't use.
D — Dependency Inversion
High-level modules depend on abstractions, not concrete implementations. The foundation of testability.
CAP Theorem & Data Consistency
CAP Theorem — Pick Two (in practice: CP or AP)
ACID (Traditional)
- Atomicity — all or nothing
- Consistency — valid state to valid state
- Isolation — concurrent txns don't interfere
- Durability — committed data survives crashes
Use for: financial transactions, inventory
BASE (Distributed)
- Basically Available — system stays up
- Soft State — state may change over time
- Eventual Consistency — replicas converge
Use for: social feeds, analytics, caching
Domain-Driven Design (DDD) — Key Concepts
Ubiquitous Language
Shared vocabulary between devs and business — used in code, docs, and conversations
Bounded Context
Explicit boundary within which a domain model applies. "Order" means different things in Sales vs. Shipping
Aggregates
Cluster of entities treated as a single unit for data changes. One entity is the Aggregate Root
📋 Chapter 3 — Summary
- SOLID — five principles for maintainable, extensible code at any scale
- CAP theorem — in distributed systems, choose between CP (consistency) and AP (availability)
- ACID for strong consistency; BASE for distributed, eventually-consistent systems
- DDD — model complex domains with bounded contexts, ubiquitous language, and aggregates
04
Chapter Four · System Design
Designing Systems
Practical patterns and strategies for building scalable, reliable, and maintainable systems — from caching to consistency.
Scaling
- Vertical: bigger machine (simple, has limits)
- Horizontal: more machines + load balancer
- Read replicas, sharding, auto-scaling
Load Balancing
- Distributes traffic across healthy instances
- L4 (TCP) fast; L7 (HTTP) content-aware
- API Gateway for auth, rate-limiting, routing
Caching
- Cache-Aside: check cache → miss → load from DB
- Write-Through: write to both simultaneously
- TTL, eviction (LRU/LFU), CDN for static
Data Consistency Patterns
| Pattern | How It Works | Trade-off |
|---|---|---|
| Strong Consistency | Every read returns the latest write | Limits availability & performance |
| Eventual Consistency | Reads may be temporarily stale — replicas converge | Simpler, faster — but stale reads possible |
| Saga Pattern | Sequence of local transactions + compensating actions | Complex failure modes; no distributed txn |
| Outbox Pattern | Write event to outbox table in same DB transaction | Guarantees atomicity — needs separate publisher |
Deep dive → Reducing Coupling (Structural, Instantiation, Call Dependencies)
📋 Chapter 4 — Summary
- Scale horizontally with stateless services behind a load balancer
- Cache aggressively — Cache-Aside is the most common pattern
- Saga replaces distributed transactions in microservices
- Outbox pattern guarantees atomicity between state change and event publishing
05
Chapter Five · Quality Attributes
Quality Attributes — The "-ilities"
Non-functional requirements that define how well a system performs — often more important than features, and much harder to retrofit.
Scalability
- Handle increased load by adding resources
- Horizontal (more instances) vs. vertical (bigger hardware)
- Measure: requests/sec, concurrent users under target latency
Reliability & Availability
- 99.9% uptime = 8.76 hours downtime/year
- Redundancy, graceful degradation, chaos engineering
- Multi-AZ, replicas, health checks, circuit breakers
Security
- Defence in depth — network, app, data layers
- AuthN (OAuth2/JWT), AuthZ (RBAC/ABAC)
- Encryption in transit (TLS) & at rest (AES-256)
- Input validation, least privilege, OWASP Top 10
Observability
- Three pillars: Metrics, Logs, Traces
- Distributed tracing with correlation IDs
- SLOs, SLIs, alerting on threshold breaches
- Grafana + Prometheus / CloudWatch
📋 Chapter 5 — Summary
- Quality attributes are designed in by architecture — not tested in later
- Scalability: stateless services + horizontal scaling
- Reliability: redundancy, graceful degradation, chaos engineering
- Security: defence in depth, least privilege
- Observability: metrics + logs + traces — the three pillars
06
Chapter Six · Real World
Architecture Case Studies
How major companies solve complex architectural challenges at scale — and what we can learn from their decisions.
Netflix — Global Streaming
- Microservices on AWS — hundreds of services via REST & event streams
- Open Connect CDN — custom edge servers at ISPs
- Resilience: Hystrix (circuit breaker), Chaos Monkey (fault injection)
- Data: Cassandra + EVCache + Kafka
- Lesson: Design for failure — every component has fallback behaviour
Google — Search & Infrastructure
- MapReduce — distributed data processing at massive scale
- Spanner — globally distributed SQL with strong consistency (TrueTime)
- Borg → Kubernetes — internal orchestration → open source
- Lesson: Build infrastructure abstractions that scale. Invest in platforms
Twitter — Real-Time Feeds
- Fan-out problem: celebrity tweet → millions of timelines
- Hybrid: fan-out on write for most; fan-out on read for celebrities
- Stack: Scala/JVM, Redis, Kafka, Manhattan (K/V store)
- Lesson: Hybrid strategies beat pure approaches — optimise for the common case
Spotify — Microservices at Scale
- Squad model: autonomous cross-functional teams own services end-to-end
- Backstage: internal dev portal for service catalogue (now open-source)
- Data: Kafka + Dataflow + BigQuery for recommendations
- Lesson: Conway's Law in action — org structure shapes system architecture
📋 Chapter 6 — Summary
- Netflix: design for failure — circuit breakers, chaos engineering
- Google: invest in infrastructure abstractions that scale
- Twitter: hybrid strategies beat pure approaches
- Spotify: org structure mirrors system architecture (Conway's Law)
Go deeper → Software Architecture Foundation — 12 in-depth pages covering fundamentals, design principles, patterns, interfaces, quality tactics, coupling, data modeling, communication, documentation, quality evaluation, examples, and reference materials.
Summary — Software Architecture at a Glance
01 · Introduction
What Is Architecture?
- Structure + trade-offs + communication + evolution
- Architect = collaborative technical leader
- Every decision is a documented trade-off
02 · Styles
Architecture Styles
- Monolith → Modular → Service-Based → Microservices
- Event-Driven for loose coupling
- Start simple, evolve when needed
03 · Principles
Design Principles
- SOLID — SRP, OCP, LSP, ISP, DIP
- CAP: choose CP or AP in distributed systems
- DDD: bounded contexts, ubiquitous language
04 · System Design
Designing Systems
- Scale horizontally with stateless services
- Cache-Aside, Write-Through, CDN
- Saga & Outbox for data consistency
05 · Quality
Quality Attributes
- Scalability, reliability, security, observability
- Quality is designed in, not tested in
- Metrics + Logs + Traces = observability
06 · Case Studies
Real-World Lessons
- Netflix: design for failure
- Google: infrastructure abstractions
- Twitter: hybrid fan-out strategies