Systems Architecture
Published on
System design connects product requirements to technical boundaries and operating consequences. A strong design explains what must be true, which alternatives were considered, how the system fails, and how the organization will operate it over time.
Design sequence
- Clarify users, critical journeys, scale, latency, consistency, durability, security, compliance, and cost constraints.
- Define APIs, data ownership, trust boundaries, and the simplest architecture that can meet the requirements.
- Estimate traffic, storage, working set, fan-out, and growth to identify likely constraints.
- Model failure domains, overload, partial failure, recovery, and safe change.
- Choose data, messaging, caching, and compute components from their guarantees and operating model.
- Define observability, SLOs, capacity, deployment, migration, and ownership.
- Record tradeoffs, rejected alternatives, and conditions that should trigger redesign.
Curated concepts
- Consistency and CAP: reason about behavior during network partitions rather than labeling products with one acronym.
- Load Balancing: distribute work while preserving health, fairness, and failure isolation.
- Caching: trade freshness, hit rate, invalidation complexity, and failure behavior.
- Replication: distinguish availability, durability, read scaling, and recovery.
- Messaging: design delivery semantics, ordering, idempotency, backpressure, and replay.
- Event-Driven Architecture: choose between event logs, job queues, and durable workflow orchestration.
- Web Application Architecture: connect edge, application, data, and asynchronous processing.
The remaining folders contain retained course and interview study notes. They are useful references but are separated from the curated architecture path in navigation.
Last updated on