Architecture Styles — Deep Dive

Level: Beginner → Intermediate
Pre-reading: 01 · Architectural Foundations

The Evolution of Architecture Styles

Software architecture has evolved in response to changing business needs, team structures, and technology capabilities. Understanding this evolution helps you make informed choices about where your system sits on the spectrum.

graph LR
    A[Monolith] --> B[Modular Monolith]
    B --> C[SOA]
    C --> D[Microservices]
    D --> E[Serverless]
    D --> F[Event-Driven]
    E --> G[Edge Computing]

Monolith — The Starting Point

A monolith is a single deployable unit containing all application logic, typically sharing one database.

When Monolith Is the Right Choice

• Early-stage startups — speed to market matters more than scalability
• Small teams (< 10 developers) — coordination overhead of microservices isn't justified
• Unclear domain boundaries — you don't know where to split yet
• Simple CRUD apps — no complex business logic warranting separation

When to Move Away from Monolith

• Deployments are slow and risky (everything deploys together)
• Teams step on each other's code constantly
• Scaling is inefficient (scale the whole app for one hot path)
• Technology lock-in (can't adopt new tech for one component)

Modular Monolith — The Stepping Stone

A modular monolith maintains a single deployable unit but enforces strict internal boundaries between modules. Each module owns its data and communicates via well-defined interfaces.

graph TD
    subgraph Modular Monolith
        A[Order Module] -->|Interface| B[Payment Module]
        B -->|Interface| C[Inventory Module]
        A -->|Interface| C
    end
    subgraph Single DB
        D[(Orders Schema)]
        E[(Payments Schema)]
        F[(Inventory Schema)]
    end
    A --> D
    B --> E
    C --> F

Tools: Spring Modulith, Java 9+ modules (JPMS), .NET projects/assemblies

Service-Oriented Architecture (SOA)

SOA emerged in the early 2000s as an enterprise integration pattern. Services communicate via an Enterprise Service Bus (ESB) — a centralized middleware handling routing, transformation, and orchestration.

SOA vs Microservices

Microservices — Independent Services at Scale

Microservices are small, independently deployable services, each owning its data and business capability.

Microservices Trade-offs

Prerequisites for Microservices Success

• [ ] Mature CI/CD pipeline with automated testing
• [ ] Container orchestration (Kubernetes)
• [ ] Observability stack (logs, metrics, traces)
• [ ] Service discovery and load balancing
• [ ] Clear domain boundaries (DDD)
• [ ] Team structure aligned with services

Serverless / FaaS — Functions as a Service

Serverless abstracts infrastructure entirely. You deploy functions; the cloud provider handles scaling, availability, and billing (per invocation).

Serverless Trade-offs

When to Choose Serverless

• Bursty, unpredictable workloads — pay only for what you use
• Event processing — file uploads, webhooks, queue consumers
• APIs with low/moderate traffic — cost-effective for small scale
• Scheduled jobs — cron-like tasks without managing servers

When NOT to Choose Serverless

• Low-latency requirements — cold starts are unpredictable
• Long-running processes — execution limits (15 min on AWS Lambda)
• Stateful workloads — functions are ephemeral
• High-volume, consistent traffic — containers may be cheaper

Event-Driven Architecture — Events as First-Class Citizens

Event-driven architecture uses asynchronous events as the primary integration mechanism. Producers emit events; consumers react independently.

graph LR
    P1[Order Service] -->|OrderPlaced| EB[Event Bus]
    P2[Payment Service] -->|PaymentCompleted| EB
    EB --> C1[Inventory Service]
    EB --> C2[Notification Service]
    EB --> C3[Analytics Service]

→ Deep Dive: Event-Driven Architecture for patterns, Kafka, CQRS, and Saga

Choosing an Architecture Style — Decision Framework

graph TD
    A[New Project] --> B{Team size < 10?}
    B -->|Yes| C{Domain understood?}
    C -->|No| D[Monolith]
    C -->|Yes| E[Modular Monolith]
    B -->|No| F{Clear bounded contexts?}
    F -->|No| E
    F -->|Yes| G{Ops maturity high?}
    G -->|No| E
    G -->|Yes| H[Microservices]
    H --> I{Bursty workloads?}
    I -->|Yes| J[Consider Serverless for some services]