Cloud Architecture
Intermediate 15 min read Cloud Architecture

Reference Architectures

Start from proven shapes, adapt deliberately

The battle-tested shapes to start from: 3-tier web, event-driven, data/analytics, microservices, serverless. Understand the canonical diagram, when it fits, and its classic failure modes — then adapt, don't reinvent.

reference architecture3-tierevent-drivenmicroservicesblueprintpatterns
Prerequisites: Architecture Principles
Before we start

What you will learn

  • Recognize the canonical reference architectures
  • Pick the right shape for a workload's profile
  • Adapt known shapes safely (and know their failure modes)
In 60 seconds

Reference architectures: 3-tier (web/API + app + DB; classic, cheap-ish), serverless (events + functions + managed services), data/analytics (ingest → lake → warehouse → BI), microservices (decomposed + API gateway + per-service data). Each is a documented starting point with known strengths and failure modes.

Introduction

What is this?

3-tier: ALB/App server + stateless app tier + managed DB; scales horizontally at tier 2, tags on statelessness. Serverless event-driven: API GW → Lambda → managed services (queues, DB, object) — spiky/fan-out, cost idle-zero, no overs; watch cold starts + state. Data/analytics: object storage (lake) + processing (EMR/Dataflow/Spark) + warehouse (Redshift/BigQuery/Synapse) + BI (QuickSight/Looker) — batch/streaming ingestion patterns. Microservices: gateway + services + per-service DB, orchestration (K8s), observability, contracts (OpenAPI/AsyncAPI). Provider-specific sets: AWS (some 3-tier, think agendas), Azure (WebApp/reference-architectures), GCP (blueprints). Adaptation rules: never copy blind — the failure modes are built in (spiky layers, stateful hints, network costs, ops overhead). Matching: pick by profile (traffic shape, team size, data volume), not by fashion.

Motivation

Why do you need it?

  • Reference architectures encode decades of lessons — starting there saves the reinvention tax.
  • Known failure modes (spiky, stateful, network-heavy) are documented, so adaptation is informed.
  • They give a team a common vocabulary and diagram to reason about.
  • Provider blueprints are kept current by the platform — a fresh starting point each release.
Think about it

Mental model

Imagine

An architect starting from a proven floor plan, not sketch #47 from nothing

Think of

Reference architecture

The plan (3-tier, etc.) is a starting line, not a cage: you adjust walls for the family (workload), but you keep the load-bearing patterns that made it safe.

Mechanics

How it works

  • Match the workload profile (traffic shape, team, data) to a reference shape.
  • Adopt the canonical pieces (LB + stateless tier + managed DB, or gateway + funcs).
  • Document which reference pieces you keep, which you replace — and why.
  • Encode as a blueprint template (IaC module) for fast repeat.
  • Review failure modes against your profile before going live.

3-tier reference.

Clients
Web/API tier
App tier
Data tier
Ops
Hands-on

Examples

Match: which shape?

Match: which shape?
# Workload: read-heavy catalogue + rare writes (spiky bursts seasonal)
#   → serverless (API GW + Lambda + managed DB w/ cache) if spiky, cheap-idle;
#   → 3-tier if steady reads with occasional write spikes, more control.
# Workload: 10k DAU low-latency sessions, small team
#   → 3-tier + managed DB: simplest ops, fewest moving parts.
# Workload: streaming telemetry, heavy analysis
#   → data reference: ingest stream → lake, batch/stream processors, warehouse + BI.

Fit the shape to traffic + team capacity first; the pattern is a starting point, not an automatic pick.

Real world

In production

  • Blueprints-as-IaC modules so the reference is a deployable 'start'.
  • Watch failure modes: serverless cold-start SLA, microservices observability, 3-tier DB scaling floor.
  • Per-service cost + reliability baselines so shapes get compared with data.
Guidelines

Best practices

  • Start from an official blueprint for the provider, then adapt in the ADRs.
  • Document the 'kept vs replaced' for each reference — the paper trail of the design.
  • Match by profile: traffic shape, team capacity, data volume, latency SLA.
  • Keep the reference as a deployable template (IaC), not a PowerPoint.
  • Know the reference's classic failure mode before you pick it (see common mistakes).
Watch out

Common mistakes

  • 3-tier with stateful app instances (drift, no horizontal scale).
  • Serverless for a steady hot-path with tight p99 (cold start + per-call overhead).
  • Microservices at 3-person team size → observability + ops tax you can't pay.
  • Copying a reference diagram without its data layer choices (multi-AZ DB, cache).
When things break

Debugging tips

  • A 'reference' deployment 5xxs under spike → check the shape's weak layer (DB single write path in 3-tier; cold starts in serverless).
  • Cost balloon on serverless → poll-heavy or fan-out; switch to committed/batch where shape says so.
  • Microservices 'simpler' turned fractal → start with service boundaries borrowed from the reference, don't freehand them.
  • Blueprint drift → the IaC module got edited per-team; re-publish and align on one maintained reference.
Interviews

Interview checkpoint

Practice

Hands-on lab

Adapt a Reference Architecture to a Workload
40 min · intermediate
In progress
Objectives
  • Choose a reference shape for a given workload
  • Sketch tiers + data layer, noting kept vs replaced
  • Document the failure modes and adaptation

Adapt a Reference Architecture to a Workload

40 min · intermediate

0/3 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

The shape with the least ops tax for a small team + steady load:

2

Starting from a reference means:

Go deeper

Official documentation

AWS architecture center
docs
Azure reference architectures
docs
GCP solutions
docs