LearningTree

Examples & Case Studies

Reference architectures, the distinction between styles, patterns, and design patterns, real-world case studies, and migration strategies — architecture learned through practice.

01
Chapter One · Terminology

Architectural Styles vs. Patterns vs. Design Patterns

These three terms are often confused. They operate at different levels of scope — from the shape of the entire system down to code-level solutions within a single component.

🏙️

Architectural Style

  • Defines the overall shape and vocabulary of the entire system
  • Client-server, layered, event-driven, REST, pipe-and-filter
  • Analogy: city planning
🏠

Architecture Pattern

  • Solves a specific recurring problem at the system/subsystem level
  • MVC, CQRS, Saga, Circuit Breaker, Strangler Fig
  • Analogy: building design
🧱

Design Pattern

  • Solves a code-level design problem within a component
  • Strategy, Observer, Factory, Decorator, Singleton
  • Analogy: interior design
Scope Hierarchy — Style → Pattern → Design Pattern
ARCHITECTURAL STYLE Entire system shape Client-Server · Layered Event-Driven · REST 🏙️ City Planning ARCHITECTURE PATTERN System / subsystem level MVC · CQRS · Saga Circuit Breaker · Strangler Fig 🏠 Building Design DESIGN PATTERN Code / class level Strategy · Observer Factory · Decorator 🧱 Interior Design
You can mix styles and patterns — e.g., a microservices style using the CQRS pattern with the Strategy design pattern inside each service.
📋 Chapter 1 — Summary
  • Architectural Style — defines the overall shape and vocabulary of the entire system (city planning)
  • Architecture Pattern — a proven solution for a recurring problem at the system/subsystem level (building design)
  • Design Pattern — a code-level solution within a single component (interior design)
  • Wider scope → narrower scope: Style → Pattern → Design Pattern
  • You can combine styles and patterns freely within one system
02
Chapter Two · Reference Architectures

Common Reference Architectures

Reference architectures are proven blueprints for common application types. They provide a starting point — not a rigid prescription — that you adapt to your specific requirements and constraints.

🌐

3-Tier Web Application

  • Presentation → Application → Data
  • Stateless app tier enables horizontal scaling
📨

Event-Driven Architecture

  • Components communicate through events via a broker
  • Strong decoupling, eventual consistency
⚙️

Batch Processing (ETL)

  • Extract → Transform → Load pipelines
  • Pipes-and-filters pattern for data processing
📱

Backend for Frontend (BFF)

  • Each client type gets its own tailored backend
  • Prevents bloated "one API for all" syndrome
3-Tier Web Application

The most common architecture for business applications — a presentation tier, a stateless application tier, and a data tier.

3-Tier Architecture — Presentation → Application → Data
Presentation Browser / Mobile App React · Angular · Flutter 🌐 CDN-served static assets HTTPS Application Business Logic (Stateless) REST API · GraphQL ⚖️ Load balanced TCP Data Persistence Layer PostgreSQL · MongoDB · Redis 🔄 Replicated
Quality FocusArchitectural Tactic
ScalabilityStateless app tier → horizontal scaling behind a load balancer
AvailabilityMultiple app instances, database replication, health checks
SecurityHTTPS, authentication middleware, input validation, CORS
PerformanceCDN for static assets, caching layer (Redis), connection pooling
Event-Driven Architecture

Components communicate through events — immutable facts about things that happened. Producers publish events to a broker; consumers subscribe and react independently.

Event-Driven — Producers → Event Bus → Consumers
Order Svc producer User Svc producer 📨 Event Bus Kafka · RabbitMQ · SNS+SQS orders.* · users.* · payments.* Notification Svc Analytics Svc Inventory Svc Producers don't know consumers — new consumers subscribe without changing producers
Quality FocusArchitectural Tactic
Loose CouplingProducers don't know consumers; events are immutable facts
ScalabilityConsumers scale independently based on throughput needs
ResilienceMessages persist in broker even if a consumer is temporarily down
ConsistencyEventual consistency — requires careful event ordering & idempotency
📋 Chapter 2 — Summary
  • 3-Tier Web: Presentation → stateless application → data; most common reference architecture
  • Event-Driven: Components communicate through events via a broker — loose coupling, eventual consistency
  • Batch (ETL): Extract → Transform → Load pipelines using the pipes-and-filters pattern
  • BFF: Each client type (web, mobile) gets its own tailored backend API
  • Reference architectures are starting points — adapt them to your specific constraints
03
Chapter Three · Architecture Spectrum

Monolith vs. Microservices — The Spectrum

This is not a binary choice. The reality is a spectrum — from a single deployable monolith all the way to hundreds of fine-grained microservices. Start simple and evolve when you have a clear need.

The Monolith-to-Microservices Spectrum
Monolith Single deployable Simple operations Modular Monolith Clean internal modules Single deployment Service-Based Few coarse services (3–8 services) Microservices Many small services (50+ services) ✓ Start here for most projects — move right ONLY when you have a clear need ← Simpler operations · Fewer failure modes ·········· Independent deployment · Independent scaling →
Key principle: Start with a well-structured modular monolith. Extract services only when you have clear domain boundaries, team boundaries, and a genuine need for independent deployment. You can always extract later — you can't easily merge back.
📋 Chapter 3 — Summary
  • Monolith vs. microservices is a spectrum, not a binary choice
  • Start with a modular monolith — extract services only when you have a clear need
  • Moving right on the spectrum adds operational complexity (CI/CD, monitoring, tracing)
  • You can always extract later — you can't easily merge back
04
Chapter Four · Real-World Examples

Case Studies

Architecture is best learned by studying how others have solved real problems — and by understanding why they made specific trade-offs. Every decision has consequences.

Case Study — E-Commerce Platform

An e-commerce platform (simplified Amazon). Here's how architecture decisions map to quality requirements and trade-offs.

E-Commerce Domain Decomposition — Each Service Owns Its Data
📦 Catalog Products · Search read-heavy 🛒 Order Create · Track ACID consistent 📊 Inventory Stock levels event-sourced 💳 Payment Stripe · PayPal PCI isolated 📧 Notify Email · SMS · Push fire-and-forget 📨 Kafka Event Bus — OrderPlaced · PaymentProcessed · StockReserved Each service owns its own database — no shared databases Services communicate ONLY through events or explicit API calls Each service maps to one bounded context (DDD)
DecisionRationaleTrade-off
Microservices5 teams, independent deployment, different scaling needsOperational complexity; CI/CD, monitoring, tracing investment
Kafka Event BusLoose coupling; independent evolution; audit trailEventual consistency; harder debugging; schema evolution
CQRS for Catalog10:1 read-to-write ratio; different data modelsTwo data stores to maintain; sync lag
Saga for Order flowNo distributed transactions; each service owns its dataCompensating transactions on failure; complex failure modes
Case Study — Legacy Modernization with Strangler Fig

A 15-year-old monolithic application needs modernization. Rewriting from scratch is too risky. Instead, use the Strangler Fig pattern — gradually replace pieces while the system stays fully operational.

Strangler Fig — Gradual Migration (Always in a Working State)
Phase 1: Start Legacy Monolith 100% of traffic Phase 2: Extract Legacy (~70%) New Service (~30%) Phase 3: Complete Legacy (tiny remnant) New Services ~95% of traffic Route traffic gradually from legacy to new services — zero big-bang risk, always in a working state
How It Works
  • Put a proxy/facade in front of the monolith that routes all traffic
  • Extract one capability at a time as a new service behind the proxy
  • Route traffic gradually — feature flags, canary releases
  • Repeat until the legacy monolith is empty
Lessons Learned
  • Start with a monolith — extract only when domain and team boundaries are clear
  • Invest in observability early — distributed tracing, centralized logging, metrics
  • Event schema evolution is hard — use a schema registry from day one
  • Test failure modes — chaos engineering is not optional for distributed systems
📋 Chapter 4 — Summary
  • E-Commerce case study: domain-driven decomposition, event bus, CQRS, Saga — every decision is a trade-off
  • Strangler Fig: gradual migration from legacy — always in a working state, zero big-bang risk
  • Named after a tropical fig that grows around a host tree, eventually replacing it entirely
  • Every architecture decision is a trade-off — document the rationale, not just the choice
Summary — Examples & Case Studies at a Glance
01 · Terminology

Styles vs Patterns

  • Style = system shape (city planning)
  • Pattern = subsystem solution (building design)
  • Design Pattern = code-level (interior design)
02 · Reference Architectures

Proven Blueprints

  • 3-Tier: stateless app tier → horizontal scaling
  • Event-Driven: loose coupling via broker
  • ETL & BFF for specialized use cases
03 · Spectrum

Monolith → Microservices

  • It's a spectrum, not a binary choice
  • Start modular monolith, extract when needed
  • You can extract later; can't merge back
04 · Case Studies

Real-World Lessons

  • Domain decomposition with event bus
  • Strangler Fig for gradual migration
  • Every decision is a trade-off — document why
Software Architecture Foundation · Examples & Case Studies · LearningTree · 2026
← Quality Foundation Overview →