← Back to courses

Architecture Patterns -

All 9 categories · Every major pattern · Layered top-to-bottom as a real system flows

00Internet / Client Zone- Who initiates requests into your system

Web Browserclient

HTTP / HTTPS requests from web apps

Browser → HTTP → Server

e.g.: fetch, Axios, Next.js, React

Mobile Appclient

iOS / Android native apps calling APIs

App → REST/gRPC → Server

e.g.: React Native, Expo, Axios

3rd-Party Partnerclient

External systems integrating via API

Partner → API Key → Gateway

e.g.: OpenAPI SDKs, Stripe SDK, undici

IoT Deviceclient

Smart devices sending data to cloud

Device → MQTT/HTTP → Broker

e.g.: mqtt.js, aedes, AWS IoT SDK

Internal Serviceclient

Server-to-server internal calls

Service A → Service B

e.g.: undici, Axios, gRPC Node

↓

01Deployment & Infrastructure Patterns- How software is deployed, run, and released

Blue-Green Deploydeploy

Two identical environments. Switch traffic instantly for zero-downtime releases.

Blue(live) → deploy to Green → switch traffic → rollback if needed

e.g.: AWS CodeDeploy, Kubernetes, PM2 reload

Canary Releasedeploy

Release to a small % of users first. Monitor, then gradually increase rollout.

5% users → new version 95% → old version if OK → 100%

e.g.: Argo Rollouts, Spinnaker, LaunchDarkly SDK

Strangler Figmigration

Gradually replace legacy system piece by piece. New grows around old, strangling it over time.

Legacy ← routes shift → New old retires when fully replaced

e.g.: Incremental refactors, Express proxy routes

Serverless / FaaSdeploy

Write functions, not servers. Auto-scales, bills per invocation, zero idle cost.

Event → Function runs → scales to 0 when idle

e.g.: AWS Lambda, Cloudflare Workers, Serverless Framework

Containerizationinfra

Package app + runtime + deps into a portable container. Runs the same everywhere.

Code + Runtime + Deps → Docker Image → runs anywhere

e.g.: Docker, Kubernetes, node:alpine images

12-Factor Appmethodology

12 principles for cloud-native apps. Config in env vars, stateless processes, disposable containers.

config env · stateless · logs backing svc · dev/prod parity

e.g.: dotenv, pino logs, stateless Express/NestJS

↓

02Security Patterns- Verifying identity, controlling access, protecting data ★ applies across ALL layers

Zero Trustsecurity

Never trust, always verify. No implicit trust even inside the network perimeter.

every request → verify identity → check permissions → log all

e.g.: BeyondCorp, mTLS, SPIFFE, jose

OAuth 2.0 / OIDCauth

Delegated authorization. Login with Google: app gets a token without your password.

User → Auth Server → token App uses token to call API

e.g.: Auth0, Keycloak, Cognito, Passport.js

JWT / API Key Gatewayauth

Token-based auth enforced at the gateway. Services don't handle auth; gateway validates.

Request + JWT → Gateway validates → forward to service if valid

e.g.: Kong, AWS API Gateway, jsonwebtoken, jose

Valet Keyaccess

Give clients a limited, time-scoped token to access a resource directly.

Client → App → temp signed URL Client uploads to S3 directly

e.g.: AWS S3 presigned URLs, @aws-sdk/s3-request-presigner

Federated Identityauth

One identity across multiple systems/domains. SSO: login once, use everywhere.

IdP issues assertion Service A, B, C all trust IdP

e.g.: SAML, SSO, Active Directory, passport-saml

↓

03Integration & Gateway Patterns- How clients connect to internal services

API Gateway★ entry point

Single entry point for ALL clients. Handles routing, auth, rate-limiting, caching, load balancing before touching any service.

Client → [API Gateway] auth ✓ → route → rate limit ✓ → cache ✓ → forward to correct service

e.g.: Kong, AWS API GW, Nginx, Express Gateway

BFF - Backend for Frontendintegration

Separate backend tailored for each client type. Mobile gets a lean API. Web gets a richer one.

Mobile → BFF-Mobile → services Web App → BFF-Web → services TV App → BFF-TV → services

e.g.: Netflix APIs, Next.js API routes, NestJS

Aggregatorintegration

Calls multiple downstream services in parallel, merges all results into one single response for the client.

Client → Aggregator → [Svc A] + [Svc B] + [Svc C] ← merge → single response

e.g.: GraphQL resolvers, Apollo Server, DataLoader

Circuit Breakerresilience

Stops calls to failing downstreams to prevent cascade failures via CLOSED -> OPEN -> HALF-OPEN recovery probes.

CLOSED: requests flow normally 5 failures → OPEN: block + fallback timeout → HALF-OPEN → test

e.g.: Hystrix, Resilience4j, Polly, opossum

Retry / Fallbackresilience

Automatically retry transient failures. If retries exhaust, return cached/default fallback.

Attempt 1 ❌ → wait 100ms Attempt 2 ❌ → wait 200ms Attempt 3 ✓ OR → fallback

e.g.: axios-retry, p-retry, async-retry, Polly

Adapter / Anti-Corruption Layerintegration

Translates between incompatible interfaces or domain models. Keeps your domain clean from 3rd-party concepts.

Your Domain ← [ACL/Adapter] ← External translates models both ways your core stays clean

e.g.: SDK wrappers, zod mappers, legacy adapters

↓

04Reliability & Scalability Patterns- Keep the system up and handle load ★ applies across ALL layers

Bulkheadreliability

Isolate services into pools. One pool crashing doesn't sink the others.

Pool A: Search ✓ Pool B: Orders ✓ Pool C: Reports 💥 (isolated)

e.g.: Thread pools, K8s namespaces, Piscina

Rate Limiting / Throttlingreliability

Control how many requests a client can make in a window. Protects from abuse and ensures fair usage.

100 req/min allowed 101st request → 429 Too Many token-bucket / sliding window

e.g.: nginx rate limit, express-rate-limit, Bottleneck

Cache-Asideperformance

App manages the cache manually. Check cache first, load DB on miss, then store in cache.

req → check Redis HIT → return cached ⚡ MISS → load DB → cache → return

e.g.: Redis, Memcached, lru-cache, node-cache

Write-Through / Write-Behindcaching

Write-Through writes cache and DB sync. Write-Behind writes cache first and DB later.

Write-Through: cache + DB sync Write-Behind: cache → return DB write async later

e.g.: Redis write strategies, cache-manager, ioredis

Read Replicas / CQRS Scalingscale

Write to primary DB, read from replicas. Scale reads independently from writes.

Writes → [Primary DB] ↓ replicate Reads → [Replica 1][Replica 2]

e.g.: Postgres replicas, MySQL RDS, Prisma read replicas

Partition data horizontally across nodes by shard key. Each shard holds a slice of all data.

user_id 0–33% → Shard A 🗄 user_id 34–66% → Shard B 🗄 user_id 67–100%→ Shard C 🗄

e.g.: MongoDB sharding, Cassandra, Mongoose shard keys

↓

05Distributed Systems Patterns- How services are organized across machines

Microservices★ core

Small, independently deployable services. Each owns its own data, process, and deployment cycle.

UserSvc → [DB: Postgres] OrderSvc → [DB: Mongo] PaymentSvc→ [DB: Redis] each independent!

e.g.: Netflix, Uber, NestJS, Fastify services

SOA - Service Oriented Arch.distributed

Larger coarse-grained services communicating via an Enterprise Service Bus.

Service A ↕ ESB ↕ Service B Service C ↕ ESB ↕ Service D centralized bus

e.g.: IBM ESB, Oracle SOA Suite, Moleculer

Service Meshinfra

Infra layer for service-to-service communication. Handles retries, mTLS, tracing via sidecar proxies.

Svc A → [Proxy] → [Proxy] → Svc B proxy handles: TLS, retry, observe, load balance

e.g.: Istio, Linkerd, Envoy, OpenTelemetry Node

Sidecar Patterninfra

Deploy a helper container alongside the main service. Handles cross-cutting concerns.

Pod: [Main App] + [Sidecar] sidecar handles: logging, proxy, config, certs

e.g.: Envoy proxy, Fluent Bit, OpenTelemetry Collector

Ambassadorproxy

A proxy helper that offloads network concerns from the main service.

App → [Ambassador Proxy] → Remote proxy handles: retry, auth, logging, throttle

e.g.: Ambassador API GW, Envoy, undici proxy agent

Database per Servicedata isolation

Each microservice owns its private database. No service accesses another's DB directly.

Svc A → own DB (Postgres) Svc B → own DB (Mongo) Svc C → own DB (Redis) complete isolation ✓

e.g.: Microservices best practice, Prisma, TypeORM

↓

06Messaging & Communication Patterns- How services talk to each other asynchronously

Event-Driven Architecture★ async

Services emit events when something happens. Other services react without the emitter knowing who listens.

OrderSvc → emit: OrderPlaced ↓ (anyone subscribed) EmailSvc, InventorySvc react

e.g.: Kafka, EventBridge, EventEmitter, eventemitter2

Pub / Submessaging

Publishers push messages to topics. Multiple subscribers consume independently.

Publisher → Topic: "orders" ↓ ↓ Sub A Sub B

e.g.: Kafka, Google Pub/Sub, SNS, kafkajs

Message Queueasync

Point-to-point async messaging. Producer drops messages; consumer picks them up.

Producer → [Queue 📦📦📦] consumer pulls at own pace buffers load spikes

e.g.: RabbitMQ, SQS, BullMQ, amqplib

Event Sourcingstate

Don't store current state; store every event that ever happened and replay to rebuild state.

1. AccountOpened(100) 2. Deposited(50) 3. Withdrew(30) replay → balance = 120

e.g.: EventStore, Axon, eventstore-db-client

Saga Patterndist. tx

Manage long-running distributed transactions with compensating transactions on failure.

Order→Reserve→Charge→Ship if Charge fails: Un-Reserve ← Refund (compensate)

e.g.: Choreography, Orchestration, Temporal Node SDK

Request-Replysync

Classic synchronous call-response. Foundation of REST, RPC, GraphQL, and gRPC.

Client → request → Server ← response ← REST, gRPC, GraphQL

e.g.: REST APIs, gRPC, tRPC, Fastify, Express

↓

07Data Management Patterns- How data is stored, accessed, and kept consistent

Command Query Responsibility Segregation. Separate write models from read models.

WRITE: Command → Write DB ↓ sync/replicate READ: Query → Read DB (denorm)

e.g.: Event-sourced systems, DDD, NestJS CQRS

Polyglot Persistencedata

Use the right database technology for each specific need. Don't force one DB for everything.

Users → PostgreSQL (relational) Sessions → Redis (key-value) Products → MongoDB (docs) Social → Neo4j (graph)

e.g.: pg, ioredis, Mongoose, Neo4j driver

API Compositionquery

Query multiple services and join/aggregate results in a composer layer.

Client → [Composer] → [UserSvc] + [OrderSvc] ← merge → combined response

e.g.: GraphQL schema stitching, Apollo Gateway

Two-Phase Commit (2PC)consistency

Atomic distributed transactions across multiple DBs. Prepare, then commit or rollback.

Phase 1 — Prepare: → [DB1 ✓] [DB2 ✓] [DB3 ✓] Phase 2 — Commit all or none

e.g.: XA transactions, DTC, node-postgres tx flows

Shared Database⚠️ coupling

Multiple services share one DB. Simple but creates tight coupling and brittle schema changes.

Svc A ↘ Svc B → [Shared DB 💾] Svc C ↗ ⚠️ avoid in microservices!

e.g.: Monolith DB, legacy systems, Sequelize models

Database per Serviceisolation

Each service owns its own database schema and technology. No direct DB cross-access.

Svc A → own DB (Postgres) Svc B → own DB (Mongo) Svc C → own DB (Redis) complete isolation ✓

e.g.: Microservices gold standard, Prisma, Mongoose

↓

08AStructural / App Architecture

Layered (N-Tier)structural

Horizontal layers; each only communicates with the layer directly below. Classic and widely understood.

Presentation Layer ↓ Business Logic Layer ↓ Data Access Layer ↓ Database

e.g.: MVC frameworks, Spring, Express, NestJS

Hexagonal (Ports & Adapters)structural

Core logic isolated from external systems. External systems plug in via ports.

[UI] → (port) 🔷CORE(port) ← [DB] [API] → ← [MQ] core never knows adapters

e.g.: DDD, NestJS modules, tsyringe

Onion Architecturestructural

Domain model at the center. All dependencies point inward; infrastructure depends on domain.

[ Infrastructure [ Application [ Domain ← core ] ] ]

e.g.: DDD, Jeffrey Palermo, InversifyJS

Clean Architecturestructural

Uncle Bob's concentric rings. Source dependencies point inward, never outward.

Frameworks → Adapters → Use Cases → Entities outer changes freely inner (entities) never changes

e.g.: Robert C. Martin, NestJS, Awilix

08BUI / Frontend Patterns

Model-View-Controller. User interacts with View, Controller updates Model, View re-renders.

User → View → Controller ↑ ↓ ← Model ← classic web pattern

e.g.: Rails, Django, Laravel, Express, NestJS

Model-View-Presenter. View is passive; Presenter drives logic and tells View what to display.

View ←→ Presenter ←→ Model View is dumb — just displays Presenter drives all logic

e.g.: Android, WinForms, ASP.NET, React presenters

Model-View-ViewModel. Two-way data binding keeps View and ViewModel synchronized.

View ←── data binding ──→ ViewModel ↕ Model

e.g.: Angular, Vue, WPF, SwiftUI, MobX

Flux / Reduxstate

Unidirectional data flow. Action -> Reducer -> Store -> View.

View → dispatch(Action) → Reducer → Store → View re-render one-way, always predictable

e.g.: Redux, Zustand, Pinia, RxJS

Micro Frontendsarchitecture

Split frontend into independently deployable slices. Each team owns a vertical surface.

App Shell [Team A: Nav] [Team B: Search] [Team C: Product] [Team D: Cart] each team deploys independently

e.g.: Module Federation, Webpack 5, single-spa

Islands Architecturerendering

Default to static HTML. Hydrate only small interactive islands where needed.

Static HTML (fast 🚀) + [Island: Search JS] + [Island: Cart JS] rest = zero JS

e.g.: Astro, Fresh (Deno), Qwik, Next.js partial hydration

Security patterns (Zero Trust, OAuth, JWT) and Reliability patterns (Circuit Breaker, Bulkhead, Rate Limiting, Cache) are cross-cutting: they apply at every layer above, not just their designated row.