Enterprise Architecture Patterns Home

Introduction

Enterprise Architecture Patterns: From Monoliths to Planet-Scale Systems is a staff-level course on system architecture — not Gang-of-Four design patterns. You will learn the decisions Amazon, Netflix, Uber, Google, Stripe, Airbnb, and LinkedIn engineers make when traffic, teams, and failure modes outgrow the first working design.

Real production story

A principal engineer joined a unicorn fintech with 400 microservices and no documented boundaries. Every "quick fix" crossed three databases. A routine deploy triggered a payment reconciliation bug that took 36 hours to unwind. The fix was not more Kubernetes — it was teaching architects to reason about quality attributes, bounded contexts, sagas, and strangler migrations. This course is that curriculum: the patterns actually used when systems must survive Black Friday, regulatory audit, and 10× team growth.

Business problem

Why senior engineers need this course: Most teams can draw boxes on a whiteboard. Few can defend why those boxes exist, what breaks first at scale, and how to migrate without stopping the business.

• Scale events: Prime Day, New Year's Eve rides, Super Bowl streams — architecture fails at interfaces, not inside a single class.
• Organizational scale: Conway's Law wins unless you align service boundaries with team ownership and domain language.
• Career ceiling: Staff and principal loops test trade-off reasoning, not pattern vocabulary.

Architecture overview

Course map — follow modules in order or jump by need:

• Module 1 — Architecture Foundations: Quality attributes, scalability, availability, reliability, observability, ADRs.
• Module 2 — Domain Driven Design: Bounded contexts, aggregates, domain events, repositories.
• Module 3 — Monolith Patterns: Modular monolith, hexagonal, clean, onion architectures.
• Module 4 — Microservices Patterns: Decomposition, database-per-service, API gateway, BFF, discovery.
• Module 5 — Distributed Systems: Saga, outbox, CQRS, event sourcing, idempotency, circuit breaker.
• Module 6 — Event Driven Architecture: Kafka, RabbitMQ, streaming, choreography vs orchestration.
• Module 7 — Cloud Native: Kubernetes, sidecar, service mesh, Istio.
• Module 8 — Migration: Strangler fig, branch by abstraction, anti-corruption layer.
• Module 9 — Multi-Tenant: Isolation models from shared schema to separate database.
• Module 10 — Architecture Interviews: Staff loops, system design, trade-offs, whiteboarding.

Architecture motivation

This course teaches decision-making: For every pattern you will see business pressure, production incidents, diagrams, data flows, failure modes, security, enterprise case studies, code, interview questions, and review checklists.

• 10 modules from foundations through architecture interviews.
• 64 lessons each structured for architects who ship, not academics who diagram.
• Real companies as case anchors — not anonymous "Company X."

Internal architecture

How to use this course as a staff engineer:

1. Read Business problem + Real production story
2. Sketch System design diagram yourself BEFORE reading Internal architecture
3. Compare your Data flow to the lesson — gaps = learning
4. Memorize Trade-offs, not definitions
5. Run Architecture review checklist on your current system
6. Practice Interview questions out loud — 45 min per lesson

Data flow

Recommended path: Complete Module 1 before interviews. Pair Module 2 with Module 4 before splitting services. Study Module 5 before any distributed transaction. Module 8 before any migration program.

• Practitioners: Jump to the module matching your current program (migration, multi-tenant, mesh).
• Interview prep: Module 1 + 5 + 10 in two weeks.
• Platform teams: Module 6 + 7 for paved-road design.

System design diagram

The course follows the journey most planet-scale companies take — deliberately, with reversibility:

Production code example

Start today — 30-minute exercise: Pick one production system. Write one ADR using the Module 1 template. List three quality attributes with SLOs. Identify one strangler slice for Module 8.

# ADR-001: [Decision title]
Status: proposed
Context: [Business + traffic + team constraints]
Decision: [Chosen pattern / boundary]
Consequences: [+/- trade-offs, ops cost, migration path]
Alternatives rejected: [With reasons]

Enterprise case study

How FAANG-style companies train architects: Netflix uses chaos and ADRs; Amazon uses two-pizza teams and written narratives; Stripe uses idempotency and immutable ledgers as first principles; Uber publishes migration postmortems; LinkedIn scales Kafka as nervous system.

• Common thread: Explicit trade-offs, measurable SLOs, reversible migrations.
• Your takeaway: Build the same habits on smaller systems before scale forces them.

Trade-offs

• Depth vs speed: Every lesson is long because architecture mistakes are expensive — skim intros only if you already operate at staff level.
• Patterns vs context: No pattern is universally correct — the course emphasizes forces and reversibility.
• Build vs buy: Enterprise case studies show when to adopt managed services vs own the complexity.

Security considerations

Security is woven through every module — zero trust between services, tenant isolation, rate limits, and blast-radius control are architectural, not optional plugins.

• Multi-tenant Module 9 is mandatory for B2B SaaS architects.
• Gateway + mesh Module 4/7 for mTLS and policy enforcement.

Scalability analysis

This course scales with you: Revisit quality-attribute lessons when SLOs change; revisit DDD when org chart changes; revisit distributed patterns when you add regions or tenants.

• Team lead: Modules 1–4 for alignment language with architects.
• Staff engineer: Modules 5–8 for cross-cutting programs.
• Principal: Module 10 + ADRs for org-wide standards.

Failure scenarios

Common learning anti-patterns: Treating microservices as a goal; skipping observability; copying Netflix without Netflix traffic; big-bang rewrites.

• Resume-driven architecture: Adopt Kafka/mesh because interviews — not because events dominate your domain.
• Analysis paralysis: ADRs exist to decide and move — perfect diagrams that never ship help no one.

Staff engineer insights

• Architecture courses that list patterns without incidents are resume padding — this one starts from outages and org pressure.
• If you cannot explain what you sacrificed to gain a quality attribute, you have a diagram, not an architecture.
• The goal is not to predict Amazon's next design — it is to recognize forces early enough to choose deliberately.

Interview questions

Architecture review questions

• Can you name three quality attributes your current system optimizes — with SLOs?
• Do you have written ADRs for the last three major boundaries?
• Can you draw sync vs async data flow for your highest-traffic path?
• Do you know your blast radius if one dependency fails open?
• Is there a migration path that avoids big-bang rewrite?
• Have you practiced explaining a trade-off to a non-engineer executive?

Summary

Welcome to the architecture course senior engineers wish they had before their first multi-team outage. Start with What Makes Good Architecture or jump to the module that matches your current program — but always read the business problem and trade-offs before the code.