↓Skip to main content

System Design Components

Table of Contents

Welcome to the System Design Components documentation. This site contains tables of common issues, patterns, anti-patterns, and mitigation strategies for various system components.

Available Components #

This documentation covers the following system components:

  • Distributed Logs: Common issues and patterns in distributed logging systems
  • Message Queue: Challenges and solutions for message queue architectures
  • Stream Processor: Patterns and anti-patterns for Stream Processors
  • API Gateway: Common issues in API gateway configurations
  • CDN: Common issues in CDN configurations
  • Load Balancer: Patterns for load balancing strategies
  • Search Index: Best practices and common pitfalls in search index design
  • Distributed Coordination: Leader election, distributed locks, consensus, idempotency, and coordination failure modes

Full System Designs #

End-to-end designs grounded in open specifications and production OSS source code, following the delivery framework: requirements → capacity → core entities → API → data flow → HLD → deep dives.

  • Payment Gateway: System design for a payment gateway — requirements, capacity, state machine, idempotency, connector routing, and async processing
  • Robinhood: System design for a retail brokerage — order state machine (FIX Protocol), smart order routing (NBBO/PFOF), market data pipeline (SIP/OPRA), risk engine (PDT rule, margin), options pricing (Black-Scholes), and T+1 settlement (DTCC/NSCC)
  • Metrics Monitoring: System design for a distributed metrics platform — TSDB (Head, WAL, XOR encoding), inverted index, scrape engine, PromQL execution, cardinality, OTel Collector pipeline (OTLP), alerting state machine, and long-term storage (Thanos vs VictoriaMetrics)
  • Google Docs: System design for a collaborative document editor — OT vs CRDT, YATA algorithm (Yjs), state vector sync, Automerge bloom-filter protocol, ShareDB transform pipeline, persistence, and undo/redo in a CRDT

Framework-Derived Designs #

End-to-end designs produced by mechanically applying the derivation framework: normalization → object extraction → axis assignment → invariants → DP derivation → mechanism selection (Q1–Q5) → algorithm → schema → technology → operations.

  • Bit.ly: URL shortener — slug uniqueness enforcement (CAS vs auto-increment), redirect hot path (three-layer cache: CDN → Redis → DB), click analytics pipeline (Kafka → ClickHouse), thundering herd protection, negative caching
  • Dropbox: File sync — block-level content addressing (SHA-256 as natural idempotency key), delta sync algorithm, version vector conflict detection, reconnect storm mitigation, sync cursor as derived view (not primary state)
  • Local Delivery Service: Grocery/parcel delivery — multi-item inventory reservation (Saga across items), shopper assignment (Lease with fencing token), substitution approval workflow (intent/future constraint), two-step payment (auth at order, capture at delivery)
  • News Aggregator: Article ingestion and ranking — crawl scheduler (FOR UPDATE SKIP LOCKED), near-duplicate clustering (MinHash/LSH), trending computation (Flink sliding window + Count-Min Sketch), personalized feed (CQRS + closed-loop EMA interest vector)

Derivation Framework #

  • System Design Derivation Framework: A complete, mechanical 20-step procedure from product requirements to operable system — normalization, object extraction, axis assignment (ownership/ordering/evolution), invariant classification, DP derivation, and the mechanism selection bridge (Sub-steps 6.1–6.4) that makes the choice of CAS vs Lease vs Saga vs CRDT derivable from first principles rather than pattern memorization. Includes worked examples (auction, driver dispatch, leaderboard), full pattern reference, and operational tail (SLOs, runbooks, observability, cost, evolution).
  • Mechanical System Design Interview Framework: An interview-first companion to the full framework. Reduces the flow to the critical 8 steps, forces fixed worksheets, separates HARD vs SOFT invariants, uses a deterministic write-shape decision tree (W1-W6 + Q1-Q6), and defines explicit stop conditions so candidates can derive a correct baseline design under time pressure with much less hidden judgment.

Pattern Zoo #

  • Pattern Zoo: Complete taxonomy of ~37 distributed systems patterns organized by functional requirement — write durability, concurrency coordination, read acceleration, write scaling, event flow, failure tolerance, consensus, and time/approximation. Includes 5+1 primitives, composition rules, and known gaps. Validated against Web Crawler, YouTube Top K, Dropbox, and Uber.

Strategy #

Following strategy is listed:

Language Details #

  • Java Concurrency: A deep dive into the implementation of Java’s concurrency utilities
  • Java NIO: Comprehensive coverage of Java’s non-blocking I/O framework
  • Java Collections: Internal mechanics of the Java Collections Framework