System Design (Deep Workflow)

System design is structured decision-making under constraints. The output is not a diagram—it is clarity on requirements, explicit trade-offs, and a path to evolve when load and features change.

When to Offer This Workflow

Trigger conditions:

• “Design Twitter/Instagram/WhatsApp” (interview style)
• Greenfield service, major scale milestone, multi-region, or realtime needs
• Refactoring monolith—boundaries and data ownership questions

Initial offer:

Use seven stages: (1) clarify requirements, (2) capacity & SLO sketch, (3) high-level architecture, (4) data model & storage, (5) APIs & traffic patterns, (6) reliability & failure modes, (7) trade-offs & evolution. Ask interview mode (time-boxed) vs real project (depth).

Stage 1: Clarify Requirements

Goal: Functional and non-functional requirements explicit.

Functional

• Core user actions; read vs write ratio; search, ranking, notifications?

Non-functional

• Scale: DAU, QPS, data size, growth—orders of magnitude OK if unknown
• Latency: p95/p99 targets; sync vs async acceptable?
• Consistency: can reads be stale? global ordering needed?
• Durability: loss tolerance; audit; compliance

Out of Scope

• Explicitly list non-goals to prevent scope creep in interviews and real life

Exit condition: Problem statement one paragraph; constraints bullet list.

Stage 2: Capacity & SLO Sketch

Goal: Back-of-envelope math to sanity-check bottlenecks.

Rough math

• Requests/day → QPS peak with 3–10× factor if needed
• Storage/day; replication multiplier
• Bandwidth for large payloads (images, video)

SLO mindset

• Availability vs cost; strong consistency vs latency

Exit condition: Identified likely bottleneck class: DB, network, fan-out, storage.

Stage 3: High-Level Architecture

Goal: Boxes and arrows with reasons.

Typical layers

• Clients → LB/API → services → caches/queues → databases/object storage
• CDN for static and cacheable API responses when applicable
• Async processing for heavy work (indexing, emails, ML)

Principles

• Separation of read/write (CQRS) only when justified by scale
• Idempotent workers; at-least-once messaging assumptions

Exit condition: Diagram + why not simpler (monolith) answered in one paragraph.

Stage 4: Data Model & Storage

Goal: Choose stores for access patterns, not buzzwords.

Questions

• Relational vs document vs wide-column vs graph—query patterns first
• Sharding key if huge scale; hot partitions risk
• Caching: what, TTL, invalidation
• Search: inverted index service (Elasticsearch, etc.) vs DB full-text

Consistency

• Transactions boundaries; sagas for cross-service consistency; eventual where OK

Exit condition: Schema sketch or entity list; read/write paths for top 3 operations.

Stage 5: APIs & Traffic Patterns

Goal: Interface design and operational behavior.

REST vs RPC vs GraphQL

• Trade-offs: coupling, overfetching, caching, team boundaries

Realtime

• WebSockets/SSE; presence; ordering; backpressure

Rate limiting & auth

• Gateway enforcement; user vs service identity

Exit condition: Example APIs or events for core flows; pagination strategy.

Stage 6: Reliability & Failure Modes

Goal: Failure is normal—design degradation.

Consider

• Retries with backoff; timeouts everywhere; circuit breakers
• Partial outages: read-only mode, stale cache, queue backlog
• Disaster: backup/restore, multi-region (active-active vs DR)

Observability

• Metrics, logs, traces; SLOs for critical paths

Exit condition: Top 5 failure scenarios + mitigation each.

Stage 7: Trade-offs & Evolution

Goal: Show maturity—v1 vs v2 path.

Articulate

• What you build first vs later; feature flags; strangler patterns
• Interview: summarize bottleneck and future scaling in 60 seconds

Final Review Checklist

• Requirements and non-goals clear
• Rough capacity points to bottleneck
• Architecture justified vs simpler alternatives
• Data stores match access patterns + consistency needs
• APIs/events and failure modes addressed
• Evolution path stated

Tips for Effective Guidance

• Interview: time-box depth—breadth first, then zoom one area on request.
• Always mention hot keys, fan-out, and backpressure for scale.
• Distinguish exactly-once myth—usually at-least-once + idempotency.

Handling Deviations

• Small system: still run stages lightly—habit prevents over-engineering later.
• Existing system: focus on incremental changes and data migration risks.