Architecture Walkthrough

The disciplined approach has five phases, executed in order.

Phase 1: Clarify Requirements

Distinguish functional requirements (what the system does) from non-functional requirements (how well it does it). Functional: users can post messages, followers see those messages in a feed. Non-functional: feed load latency under 100ms at the 99th percentile, 99.99% availability, five-year data retention.

Write both down explicitly before drawing anything. The F5 Review Questions framework provides a checklist: Who are the users? What are the read and write patterns? What consistency level is required? What are the latency targets? What are the failure tolerance requirements? What is the data model? What are the scale targets?

Phase 2: Estimate Scale

Back-of-envelope estimation converts product requirements into engineering constraints.

DAU = 50M users
Average posts per user per day = 2
Write QPS = (50M × 2) / 86400 ≈ 1,200 writes/sec
Read/write ratio = 100:1 (typical feed system)
Read QPS = 120,000 reads/sec
Average post size = 280 chars + metadata ≈ 1 KB
Daily write volume = 50M × 2 × 1 KB = 100 GB/day
5-year storage = 100 GB × 365 × 5 ≈ 180 TB

Scale estimates determine which architectural decisions are forced. 120,000 read QPS cannot be served by a single database. 180 TB cannot fit on a single server. Estimation is not about precision — it is about revealing constraints that eliminate naive solutions.

Phase 3: Design Components

Map requirements to the seven system archetypes (F6): Read-Heavy Store, Write-Heavy Ingest, Search & Discovery, Real-Time Messaging, Media Delivery, Marketplace, Data Intelligence. Most real systems combine two or three archetypes. Identify the primary archetype first, then the secondary.

Use the five Architecture Diagram types (F7) in sequence: Data Model (what is stored and how), Component Diagram (which services exist), Sequence Diagram (how a request flows), Data Flow Diagram (where data moves and transforms), Deployment Diagram (how services map to infrastructure).

Phase 4: Evaluate Tradeoffs

For each major design decision, name the tradeoff explicitly using AT codes. “We use eventual consistency here” is incomplete. “We accept AT1 (Consistency/Availability) in favour of availability because reads must not block on cross-region replication” is a decision.

Every decision has a cost. The cost of eventual consistency is FM4 (Data Consistency Failure) — the risk that a user sees stale data. Name the failure mode and state the mitigation.

Phase 5: Plan Evolution

Every system will be different in two years. Design for the next ten times, not the next thousand times. Identify the components most likely to become bottlenecks first. Sketch what changes at 10× scale. The components that require replacement are the ones that need clean boundaries today.

Current scale     → 10× scale change
Single DB         → Read replicas + write sharding
In-process cache  → Distributed cache cluster
Synchronous calls → Async queue-based processing
Single region     → Multi-region with geo-routing