Learning Hub
🏗️

System Design & Architecture

From requirements and diagrams to scalable, reliable software architecture.

System Design Roadmap: From Requirements to Reliable Architecture

Learn system design as a sequence of decisions, using a small learning platform as the running example.

13 min readsystem-design-foundationsarchitecturescalabilityreliabilityroadmap

Functional vs non-functional requirements

Functional requirements describe behavior users need; non-functional requirements define qualities and constraints such as latency, accessibility, security, capacity, and recovery.

6 min readsystem-design-foundationspracticebeginner-friendly

High-level design vs low-level design

High-level design explains system boundaries, data flow, dependencies, and major tradeoffs; low-level design specifies components, interfaces, data models, algorithms, and failure handling.

6 min readsystem-design-foundationspracticebeginner-friendly

Estimate traffic, storage, and bandwidth

A capacity estimate converts product assumptions into requests per second, concurrency, stored bytes, and network throughput. Ranges and peak factors are more honest than false precision.

6 min readsystem-design-foundationspracticebeginner-friendly

Monolith, modular monolith, and microservices

A monolith deploys as one unit, a modular monolith enforces internal boundaries within that unit, and microservices deploy bounded capabilities independently. Team and operational needs should drive the choice.

6 min readarchitecturepracticebeginner-friendly

Stateful vs stateless services

A stateless service can handle the next request on any equivalent instance using external state; a stateful service owns durable or session state that affects placement, scaling, and recovery.

6 min readarchitecturepracticebeginner-friendly

Event-driven and pub/sub architecture

In event-driven systems, producers publish facts that happened and consumers react independently. Pub/sub reduces direct coupling but introduces retries, ordering, duplication, and observability work.

6 min readarchitecturepracticebeginner-friendly

Serverless architecture

Serverless runs functions or managed services on demand while the provider handles much of the infrastructure. You still own code, data, permissions, cost behavior, observability, and recovery.

6 min readarchitecturepracticebeginner-friendly

Vertical vs horizontal scaling

Vertical scaling gives one machine more resources; horizontal scaling adds machines. The second needs distribution, coordination, and state design, so it is not automatically better.

6 min readscale-and-reliabilitypracticebeginner-friendly

Availability, reliability, and fault tolerance

Availability measures whether a service can be used, reliability measures correct behavior over time, and fault tolerance is the design ability to continue when a component fails.

6 min readscale-and-reliabilitypracticebeginner-friendly

CAP theorem with a practical example

CAP says that during a network partition, a distributed system must choose between always returning a response and guaranteeing every response reflects the latest successful write. It does not mean choosing only two properties forever.

6 min readscale-and-reliabilitypracticebeginner-friendly

Load balancing and consistent hashing

A load balancer distributes requests across healthy targets; consistent hashing keeps most key-to-node assignments stable when nodes change, which helps partitioned caches and stateful routing.

6 min readscale-and-reliabilitypracticebeginner-friendly

Replication, sharding, and partitioning

Replication copies data; partitioning divides it; sharding commonly means application-visible horizontal partitions across database nodes. Clear terminology matters more than labels.

6 min readsystem-data-performancepracticebeginner-friendly

Latency, throughput, and bottlenecks

Latency is time per operation, throughput is completed work per time, and a bottleneck is the constrained resource that currently limits the system. Improving one metric can worsen another.

6 min readsystem-data-performancepracticebeginner-friendly

Caching and cache invalidation

A cache trades freshness and complexity for lower latency and load. A safe design states the cache key, owner, lifetime, invalidation event, and behavior on a miss or stale value.

6 min readsystem-data-performancepracticebeginner-friendly

CDN, edge, proxy, and API gateway

A CDN serves cacheable content near users, an edge layer runs limited logic near the network boundary, a reverse proxy routes and protects origins, and an API gateway applies API-specific policies.

6 min readsystem-data-performancepracticebeginner-friendly

Queues, rate limiting, and backpressure

Queues absorb bursts, rate limits protect finite capacity, and backpressure tells producers to slow down. Together they bound work instead of hiding overload until failure.

6 min readsystem-data-performancepracticebeginner-friendly

SOLID, DRY, KISS, and YAGNI

SOLID guides change-friendly responsibilities and dependencies; DRY reduces harmful duplication; KISS favors understandable designs; YAGNI delays speculative capability. These are lenses, not absolute laws.

6 min readlow-level-designpracticebeginner-friendly

UML for communicating a design

UML is a shared visual vocabulary. Use the smallest diagram that answers a question: class for structure, sequence for interaction over time, state for lifecycle, and component for boundaries.

6 min readlow-level-designpracticebeginner-friendly

Design patterns through one small application

A design pattern names a recurring design tradeoff and arrangement of responsibilities; it is useful when the forces match, not as decoration for simple code.

6 min readlow-level-designpracticebeginner-friendly

Authentication, authorization, TLS, and disaster recovery

Authentication proves identity, authorization limits actions, TLS protects data in transit, and disaster recovery restores service and data after a severe failure. These controls cover different risks and must be tested together.

6 min readlow-level-designpracticebeginner-friendly

Test a distributed system

Distributed-system tests must cover boundaries and time: retries, duplicates, delay, reordering, partial failure, clock assumptions, and recovery—not only happy-path responses.

6 min readlow-level-designpracticebeginner-friendly