System design connects requirements, capacity limits, and invariants to decisions about data and components. These notes make explicit what each mechanism protects, which failures it admits, and how to verify recovery.
Study guide: one reading
The main reading is SD: Payments and Settlement SRE Review. It brings the central explanation, invariants, workflows, capacity, diagnosis, and incidents together in a self-contained sheet. It can be studied from beginning to end without following a sequence of other articles.
The complete payments and settlement SRE case provides the E2E design and detailed decisions for reference. The notes below and Platform Engineering are optional references for expanding a specific topic; they are not required steps in the review.
Reference library
- SD: Hello Interview Framework — five delivery stages and four preparation areas for an interview, with varied practice and reasoned decisions.
- SD: Data Modeling — access patterns, relational constraints, composite indexes, normalization, and data locality.
- SD: API Design — interface styles, resources, HTTP semantics, pagination, authorization, and retries.
- SD: Object Storage — objects and metadata, direct uploads with signed URLs, multipart, and recovery across stores.
- SD: Sharding — shard keys, capacity planning, hotspots, cross-shard operations, and safe data migration.
- SD: Consistent Hashing — ring assignment, limited remapping, virtual nodes, hotspots, and coordinated migration.
- SD: Caching — cache architectures, freshness, eviction, stampedes, hot keys, and recovery without overloading the database.
- SD: Redis — keys, data structures, Cluster slots, hash tags, memory, and durability.
- SD: Message Queues — capacity, backpressure, ordering, and recovery when designing asynchronous work.
- SD: Kafka vs RabbitMQ — task queues, retained logs, replay, and delivery guarantees with idempotent consumers.
- SD: 2PC vs Saga — transaction boundaries, commit atomicity, compensations, and publication with an outbox.
- SD: Ticketing System — consistent inventory, temporary holds, and payment coordination under high demand.
- SD: Rate Limiter — a distributed design connecting shared state, atomic decisions, scalability, and recovery from failures.
- SD: Docker — images, containers, build caching, isolation, and Docker Sandboxes for agents.
Guarantees and recovery
- SD: Idempotency and Uncertain Outcomes — stable operation identity, local deduplication, and recovery when a response is lost.
- SD: Outbox, CDC, and Projection Recovery — durable publication, relays, ordering, duplicates, and rebuilding views.
- SD: Consistency, Isolation, and Authority — atomicity, isolation, freshness, and boundaries that enforce invariants.
- SD: Replication, Durability, and Recovery — acknowledgments, failover, copies across zones and regions, backups, and RTO/RPO drills.
- SD: Timeouts, Leases, and Temporary Ownership — waiting budgets, expiry, late owners, and protection at the resource.
- SD: Capacity, Backpressure, and Admission — useful work, concurrency, finite queues, and dependency budgets during bursts and failures.
- SD: Observability and Invariants — signals, identities, and concurrency and recovery drills that verify outcomes.
Traffic entry and content delivery
- SD: Load Balancing — target selection, health, connections, draining, and retries with a stable identity.
- SD: CDN — cache keys, private content, freshness, invalidation, and origin coordination.
Within Systems Lab, this path shares the axes of state, communication, failures, and observability with Homelab, which studies how to deploy, observe, and recover the infrastructure that runs the systems.