Enterprise Architecture Patterns Course
Enterprise Architecture Patterns: From Monoliths to Planet-Scale Systems — DDD, distributed patterns, event-driven, cloud-native, and staff architecture mastery.
Enterprise learning path
Architecture Foundations
- 1Enterprise Architecture Patterns HomeNext up
Enterprise Architecture Patterns: From Monoliths to Planet-Scale Systems is a staff-level course on system architecture — not Gang-of-Four design patterns.
- 2What Makes Good Architecture
Good architecture is not minimal lines of code or the trendiest topology — it is the set of structures that let Amazon-scale teams change the system safely while meeting explici…
- 3Quality Attributes
Quality attributes — availability, latency, scalability, security, modifiability — are the non-functional requirements that determine whether Netflix survives peak streaming hours.
- 4Scalability
Architectural scalability is the ability to grow traffic, data, teams, and geography without redesigning core structures.
- 5Availability
Availability is the proportion of time a system correctly performs its work — measured as nines against explicit SLOs, not uptime of individual VMs.
- 6Reliability
Reliability is the probability that a system performs correctly over time — correctness under failure, not just uptime.
- 7Maintainability
Maintainability is how cheaply a system absorbs change — new features, bug fixes, dependency upgrades, and team turnover — without proportional risk or toil.
- 8Observability
Observability is the ability to infer internal system state from external outputs — metrics, logs, traces, and events — to answer novel questions during incidents.
- 9Architectural Trade-offs
Architectural trade-offs are the explicit choices between competing quality attributes — consistency vs availability, speed vs safety, cost vs performance.
- 10Architecture Decision Records
Architecture Decision Records (ADRs) capture significant decisions with context, alternatives, and consequences — lightweight documents that prevent future teams from relitigati…
Domain Driven Design
- 11Strategic Design
Strategic design in Domain-Driven Design maps business domains to bounded contexts, defines context relationships, and aligns team topology before tactical patterns like aggrega…
- 12Bounded Contexts
Bounded contexts delimit a domain model's applicability — inside the boundary, terms and rules are consistent; across boundaries, integrate via translation, not shared entities.
- 13Ubiquitous Language
Ubiquitous language is the shared vocabulary between domain experts and engineers — reflected in code, docs, and conversation without translation layers.
- 14Aggregates
Aggregates cluster entities and value objects with one root that enforces invariants transactionally — the consistency boundary for writes in DDD.
- 15Entities
Entities are domain objects with identity that persists through state changes — distinguished by ID, not attribute values.
- 16Value Objects
Value objects describe attributes without identity — immutable, compared by value, and safe to share.
- 17Domain Events
Domain events record something meaningful that happened in the domain — past tense, immutable facts consumed by other aggregates and contexts.
- 18Repositories
Repositories persist and rehydrate aggregates — collection-like interface hiding persistence technology from domain layer.
Monolith Patterns
- 19Modular Monolith
Modular monolith keeps a single deployable artifact while enforcing hard module boundaries inside the codebase — each module owns its schema slice, exposes a narrow public API,…
- 20Layered Architecture
Layered architecture organizes code into horizontal tiers — presentation, application, domain, infrastructure — with strict dependency direction downward.
- 21Hexagonal Architecture
Hexagonal architecture (ports and adapters) places the domain at the center, surrounded by ports (interfaces) and adapters (implementations) for every external system.
- 22Clean Architecture
Clean Architecture (Uncle Bob) organizes code in concentric rings — Entities, Use Cases, Interface Adapters, Frameworks — with the Dependency Rule: source code dependencies poin…
- 23Onion Architecture
Onion architecture (Jeffrey Palermo) wraps the domain model in layers of interfaces — Domain Model at core, Domain Services, Application Services, Infrastructure — with all depe…
Microservices Patterns
- 24Service Decomposition
Service decomposition splits a system into independently deployable services aligned to business capabilities or subdomains — not technical layers.
- 25Database Per Service
Database per service gives each microservice exclusive ownership of its persistence — no other service reads or writes its tables directly.
- 26Shared Database Anti-Pattern
The shared database anti-pattern occurs when multiple microservices read and write the same database schema — creating a distributed monolith with network overhead and none of t…
- 27API Gateway
An API gateway is the single entry point for client traffic — handling routing, authentication, rate limiting, request aggregation, and protocol translation before requests reac…
- 28Backend For Frontend
Backend for Frontend (BFF) is a dedicated backend service per client type (web, iOS, Android) that aggregates microservice calls and shapes responses for that client's UX needs.
- 29Service Discovery
Service discovery lets microservices find each other's current network location (IP, port, health) without hardcoded hostnames — essential when containers scale and reschedule c…
- 30Service Registry
A service registry is the authoritative datastore of service instances, metadata, and health status that discovery clients query — Eureka, Consul, etcd (K8s), and ZooKeeper (leg…
Distributed Systems Patterns
- 31Saga Pattern
Saga pattern coordinates long-running business transactions across multiple services without a distributed two-phase commit.
- 32Outbox Pattern
Transactional outbox guarantees that domain state changes and outbound messages commit atomically in one local database transaction.
- 33CQRS
Command Query Responsibility Segregation (CQRS) separates write models (commands, transactional consistency) from read models (queries, denormalized projections).
- 34Event Sourcing
Event sourcing persists state as an append-only sequence of domain events rather than mutable rows.
- 35Distributed Transactions
Distributed transactions coordinate commits across multiple services or databases.
- 36Idempotency
Idempotency ensures repeated identical requests produce the same outcome as a single execution — the foundation of safe retries in distributed systems.
- 37Retry Pattern
Retry pattern re-invokes failed operations with controlled backoff and jitter when failures are transient — timeouts, 503s, partition leader elections.
- 38Circuit Breaker
Circuit breaker stops calling a failing dependency after error threshold, failing fast locally while the dependency recovers — then probes with half-open trials.
- 39Bulkhead
Bulkhead pattern isolates resources (thread pools, connections, queues) per dependency or tenant so failure in one compartment cannot sink the entire ship.
- 40Rate Limiting
Rate limiting caps request volume per client, tenant, or endpoint — protecting backends from abuse, accidental loops, and flash crowds.
Event Driven Architecture
- 41Event Brokers
Event brokers are the durable transport layer between producers and consumers — SNS/SQS, Amazon MSK, Google Pub/Sub, Azure Event Hubs.
- 42Kafka
Apache Kafka is a distributed commit log — partitions, replicas, consumer groups, and ISR management form the core architecture LinkedIn pioneered for activity streaming.
- 43RabbitMQ
RabbitMQ implements AMQP messaging with exchanges, queues, bindings, and acknowledgments — ideal for complex routing, RPC-over-messaging, and work-queue patterns.
- 44Event Streaming
Event streaming treats the continuous flow of domain events as a first-class data product — not a side effect of CRUD APIs.
- 45Choreography
Choreography coordinates distributed workflows through events alone — no central orchestrator.
- 46Orchestration
Orchestration coordinates multi-step distributed workflows from a central process manager that invokes services and tracks state.
Cloud Native Patterns
- 47Kubernetes Patterns
Kubernetes patterns are the operational primitives staff architects use to run distributed systems on container orchestration — deployments, services, ingress, HPA, PDB, and wor…
- 48Sidecar
The sidecar pattern deploys a helper container alongside the application container in the same pod — sharing network namespace and optionally volumes.
- 49Ambassador
The ambassador pattern deploys a proxy container that simplifies outbound connections for the application — handling retries, circuit breaking, TLS, and protocol translation.
- 50Adapter
The adapter pattern in cloud-native systems normalizes heterogeneous external interfaces — legacy protocols, varied config formats, different logging APIs — into a consistent in…
- 51Service Mesh
A service mesh is a dedicated infrastructure layer for service-to-service communication — typically implemented as sidecar proxies (data plane) managed by a control plane.
- 52Istio
Istio is the dominant open-source service mesh implementation — Envoy data plane, Istiod control plane, and Kubernetes-native CRDs for traffic, security, and observability.
Migration Patterns
- 53Strangler Fig
Strangler Fig incrementally replaces a legacy system by routing traffic slice-by-slice to new implementations while the old system continues running.
- 54Branch By Abstraction
Branch By Abstraction introduces an abstraction layer (interface) in front of a module you plan to replace, routes all callers through the abstraction, then swaps the implementa…
- 55Anti Corruption Layer
Anti-Corruption Layer (ACL) is a translating boundary that isolates your domain model from legacy or external systems whose vocabulary, invariants, and failure modes would corru…
- 56Legacy Modernization
Legacy Modernization is the disciplined program — not a single pattern — of evolving outdated systems toward target architecture using Strangler Fig, Branch By Abstraction, ACL,…
Multi Tenant Systems
- 57Shared Database
Multi-Tenant Shared Database stores all tenants' data in one physical database cluster, discriminating rows by a tenant_id column (or equivalent).
- 58Shared Schema
Multi-Tenant Shared Schema gives all tenants identical table structures within a database — the most common SaaS pattern.
- 59Separate Schema
Multi-Tenant Separate Schema gives each tenant (or tenant tier) its own namespace within a shared database instance — tenant_a.listings vs tenant_b.listings.
- 60Separate Database
Multi-Tenant Separate Database provisions each tenant (or tenant tier) with its own database instance or cluster — maximum isolation, highest cost and operational complexity.
- 61Tenant Isolation
Tenant Isolation is the cross-cutting quality attribute — not a storage model — ensuring one tenant's load, failures, and security boundaries cannot impact another.
Architecture Interviews
- 62Staff Engineer Interviews
Staff Engineer Architecture Interviews evaluate whether a candidate operates at organizational scope: defining technical direction across teams, making irreversible trade-offs l…
- 63System Design Interviews
System Design Architecture Interviews at Amazon evaluate whether candidates can design production systems under real constraints — scale, cost, failure modes, and operability —…
- 64Architecture Trade-offs
Architecture Trade-offs Interview focuses exclusively on decision quality: given competing quality attributes (latency vs consistency, velocity vs isolation, cost vs availabilit…
- 65Architecture Whiteboarding
Architecture Whiteboarding is the skill of communicating system design in real time — boxes, arrows, and narrative that a mixed audience (engineers, PMs, bar-raisers) can follow.