DOCSEARCHbyAlgolia
Submit Docs

System Design Notes

repository·main·Indexed 27 days ago

https://github.com/liquidslr/system-design-notes

Notes and case studies for large-scale distributed systems. Covers scaling strategies (vertical, horizontal, sharding), database replication, caching, CDNs, and message queues. Includes guidance on back-of-the-envelope estimations, availability calculations, a 4-step system design interview framework, and detailed implementation strategies for rate limiting algorithms and distributed environments.

Tokens
36.2K
Snippets
28
Records
220
Agent score
96%

What's inside system-design-notes

  1. Overview of Distributed Message Queue Design

    main

    This chapter outlines the design of a distributed message queue capable of advanced features like long data retention and repeated message consumption. Unlike traditional message queues, this design focuses on preserving message order and supporting configurable delivery semantics.

    Key Benefits

    • Decoupling: Separates producers from consumers for independent updates.
    • Scalability: Allows independent scaling of producers and consumers.
    • Availability: Increases system resilience by buffering messages if components fail.
    • Performance: Enables asynchronous production without waiting for consumer confirmation.

  2. Overview of S3-like Object Storage Design

    main

    This design study covers the architecture of an S3-like object storage system. Key concepts include:

    • Storage Types: Comparison between object, block, and file storage.
    • Core Operations: Implementing uploading, downloading, listing, and versioning of objects within a bucket.
    • System Architecture: Separation of the data store (actual object data) and the metadata store (object attributes and locations).
    • Reliability and Scalability: Implementation of replication, erasure coding, multipart uploads, and sharding to ensure durability and performance.

  3. Compare Point-to-Point and Publish-Subscribe Messaging Models

    main

    Distributed systems typically use one of two messaging models:

    Point-to-Point Model

    • A message is sent to a specific queue.
    • Each message is consumed by exactly one consumer.
    • Once acknowledged, the message is removed from the queue.
    • Typically does not support data retention.

    Publish-Subscribe Model

    • Messages are associated with a topic.
    • Consumers subscribe to a topic and receive all messages sent to that topic.
    • This model is common in event streaming platforms.

  4. Data Store Components and Responsibilities

    main

    The S3-like object storage data store consists of three main components:

    1. API Service: The entry point for client requests.
    2. Data Routing Service: A stateless service (scalable via more servers) that provides a RESTful or gRPC API. It queries the placement service for optimal data nodes, and handles reading/writing data between the API service and data nodes.
    3. Placement Service: Determines which data nodes store specific objects by maintaining a virtual cluster map (physical topology). It also manages node health via heartbeats. For high availability, it should be deployed as a cluster of 5 or 7 replicas using Paxos or Raft consensus algorithms.
    4. Data Nodes: Store the actual object data. They run a daemon that sends heartbeats to the placement service containing disk management info (HDD/SSD count and storage usage per drive).

  5. Architectural components of a Chat System

    main

    A scalable chat system is divided into stateless and stateful components:

    • Stateless Services: Handle user signup, login, and profile management. These integrate with service discovery to recommend chat servers.
    • Stateful Services: Chat servers that maintain persistent WebSocket connections and manage message delivery and synchronization.
    • Presence Servers: Manage user online/offline status.
    • API Servers: Handle user-related operations (login, signup, profile changes).
    • Notification Servers: Send push notifications via third-party services.
    • Key-Value Store: Used for permanent chat history storage due to horizontal scalability and low latency.

  6. Design a Unique ID Generator in Distributed Systems

    main
    When designing a unique ID generator for distributed systems, the goal is to create 64-bit numerical IDs that are unique, sortable by date, and capable of high throughput (e.g., >10,000 IDs/sec). Traditional auto-incrementing keys are often unsuitable due to scalability and synchronization challenges in distributed environments.

  7. Design requirements for Ad Click Event Aggregation

    main

    When designing an ad click event aggregation system at scale (e.g., Facebook/Google scale), the following requirements must be met:

    Functional Requirements

    • Aggregate clicks: Calculate the number of clicks for a specific ad_id over the last Y minutes.
    • Top-K Ads: Return the top 100 most clicked ad_ids every minute (parameters should be configurable).
    • Filtering: Support data filtering by attributes such as ip, user_id, and country.
    • Scale: Handle massive dataset volumes (e.g., 1 billion ad clicks per day).

    Non-functional Requirements

    • Correctness: High accuracy is critical as results impact real-time bidding (RTB) and ads billing.
    • Event Handling: The system must properly handle delayed events and duplicate events.
    • Robustness: The system must be resilient to partial failures and support recovery.
    • Latency: End-to-end (e2e) latency should be kept to a few minutes at most (note: RTB itself requires <1s latency, but aggregation for billing can tolerate a few minutes).

    Scale Estimations (Reference)

    • Daily Volume: 1 billion ad clicks per day.
    • Throughput: Average 10,000 QPS; Peak 50,000 QPS.
    • Storage: 0.1KB per click $\rightarrow$ 100GB daily $\rightarrow$ 3TB monthly.

  8. Core components of a Metrics Monitoring and Alerting System

    main

    A scalable metrics monitoring system consists of five fundamental components:

    1. Data collection: Gathering metrics data from various sources (e.g., application servers, SQL databases, message queues).
    2. Data transmission: Transferring the collected data from the sources to the monitoring system.
    3. Data storage: Organizing and storing incoming data, typically using a time-series database.
    4. Alerting: Analyzing incoming data to detect anomalies and generating notifications.
    5. Visualization: Presenting the metrics through graphs, charts, and dashboards.

  9. Design a Search Autocomplete System

    main

    A search autocomplete (typeahead) system provides real-time suggestions as users type. The system is designed to return up to 5 top-k results based on query popularity (frequency).

    Key Constraints & Requirements:

    • Latency: Response time must be < 100 ms.
    • Scalability: Designed for 10 million DAU and a peak of 48,000 QPS.
    • Character Support: Initially supports lowercase English characters (can be extended via Unicode).
    • Data Growth: Handles approximately 0.4 GB of new query data daily.

  10. Understand the Stock Exchange high-level architecture

    main

    The exchange architecture is divided into three primary flows:

    1. Trading Flow (Critical Path): Optimized for low latency. Includes the Client Gateway (validation/auth), Order Manager (risk checks/wallet verification), Sequencer (deterministic stamping), and the Matching Engine (order book maintenance and matching).
    2. Market Data Flow: The Market Data Publisher consumes executions from the matching engine to build order books and candlestick charts, which are then served by the Data Service.
    3. Reporting Flow: The Reporter collects fields (client_id, price, quantity, etc.) from orders and executions to write to a database for compliance, tax, and settlement purposes. This flow is not latency-critical.

  11. Understand Google Maps System Design Scope

    main

    A high-level design for a Google Maps clone focuses on three core features:

    1. User location update: Recording real-time movement.
    2. Navigation service: Providing routes and Estimated Time of Arrival (ETA).
    3. Map rendering: Displaying the map to the user.

    Non-functional requirements to prioritize:

    • Accuracy: Directions must be correct.
    • Smooth navigation: Map rendering must be fluid.
    • Data and battery usage: Minimize client-side consumption for mobile devices.
    • Scalability and Availability: Support for massive daily active users (DAU).

  12. High-Level Architecture of a Distributed Message Queue

    main

    A distributed message queue system consists of the following architectural components:

    • Clients: Includes Producers (push messages to topics) and Consumer Groups (subscribe to topics).
    • Brokers: Servers that hold and manage multiple Partitions.
    • Data Storage: The layer responsible for storing messages within partitions.
    • State Storage: Manages consumer states (e.g., current offsets).
    • Metadata Storage: Stores system configuration and topic properties.
    • Coordination Service: Handles service discovery (tracking alive brokers) and leader election (assigning partition leaders).