ENGIMY.IO - CHEATSHEET
SYSTEM DESIGN × QUICK REFERENCE
SD
INTERVIEW REFERENCE

SYSTEM DESIGN
PATTERNS CHEATSHEET.

A comprehensive reference for system design patterns – load balancing, caching, database sharding, microservices, and more. All in one place.

REFERENCE v1.0

System Design Patterns Quick Reference

Everything you need to design scalable, resilient, and high‑performance systems.

System Design Basics

Key Principles
  • Scalability – handle growth (vertical/horizontal)
  • Availability – uptime percentage (99.9%, 99.99%)
  • Reliability – system continues to work correctly
  • Performance – latency, throughput
  • Consistency – data consistency across replicas
  • Resilience – fault tolerance and recovery
CAP Theorem
  • C – Consistency (all nodes see same data)
  • A – Availability (every request gets a response)
  • P – Partition Tolerance (network failures)
  • Can only have 2 of 3
  • CP – Consistency + Partition (MongoDB, HBase)
  • AP – Availability + Partition (Cassandra, DynamoDB)
  • CA – Consistency + Availability (RDBMS, but no partition tolerance)

Estimating Scale

// Monthly users → Daily active → Requests per second
Monthly Active Users (MAU) = 100 million
Daily Active Users (DAU) = 10 million (10% of MAU)
Peak concurrent users = 1 million (10% of DAU)
Requests per second = 10,000 (10 requests/user/day)
Read:Write ratio = 90:10

// Storage calculations
Data per user = 100 KB (profile, posts, etc.)
Total data = 100M * 100 KB = 10 TB
Daily new data = 1M * 100 KB = 100 GB
Monthly new data = 3 TB

Load Balancing Patterns

Round Robin

  • Distributes requests sequentially
  • Simple and fair
  • Doesn't consider server load

Least Connections

  • Routes to server with fewest active connections
  • Better when requests vary in duration
  • More adaptive than round robin

IP Hash

  • Hash client IP to a server
  • Session stickiness
  • Good for session‑based applications

Weighted Round Robin

  • Assign weights to servers based on capacity
  • Handles heterogeneous servers
  • More powerful servers get more requests

Load Balancer Types

  • Layer 4 (Transport) – TCP/UDP, IP address, port
  • Layer 7 (Application) – HTTP, URL, cookies, headers
  • DNS – resolves domain to IP, simple but less flexible
  • Global Server Load Balancing (GSLB) – across regions

Caching Patterns

Cache‑Aside (Lazy Loading)

  • Check cache first
  • If miss, load from DB and populate cache
  • Pros: efficient, only caches requested data
  • Cons: cache miss penalty

Read‑Through

  • Cache sits between app and DB
  • Handles all read requests
  • Always serves from cache or loads from DB
  • Pros: simplifies app logic
  • Cons: cache is always aware of data

Write‑Through

  • Write to cache and DB simultaneously
  • Strong consistency
  • Pros: no cache inconsistency
  • Cons: higher write latency

Write‑Behind (Write‑Back)

  • Write to cache, then asynchronously to DB
  • Low write latency
  • Risk of data loss if cache fails
  • Good for write‑heavy systems

Cache Strategies

  • LRU – Least Recently Used (most common)
  • LFU – Least Frequently Used
  • TTL – Time To Live (expiry)
  • Invalidation – clear cache on update
  • Cache Stampede – large number of requests for expired key

CDN (Content Delivery Network)

  • Geographically distributed caches
  • Static assets: images, CSS, JS, videos
  • Reduces latency for global users
  • Edge servers closer to users
  • Popular CDNs: Cloudflare, Akamai, Fastly

Database Patterns

Master‑Slave Replication

  • Master handles writes
  • Slaves handle reads (replicas)
  • Read scalability
  • Failover: promote slave to master

Master‑Master Replication

  • Multiple masters accept writes
  • Conflict resolution needed
  • High availability
  • Complex conflict handling

Sharding (Horizontal Partitioning)

  • Split data across multiple databases
  • Based on shard key (user_id, region, etc.)
  • Increases write capacity
  • Challenges: cross‑shard queries, rebalancing
  • Hash‑based – evenly distributes
  • Range‑based – ordered shards (user_id 1‑1000, 1001‑2000)
  • Directory‑based – lookup table for shard mapping

Partitioning vs Sharding

  • Partitioning – splitting data within a database
  • Sharding – splitting data across databases
  • Sharding is a type of partitioning (distributed)

Database Types

Type Examples Use Case
RDBMS PostgreSQL, MySQL ACID, structured data, joins
NoSQL (Document) MongoDB, Firestore Flexible schema, JSON documents
NoSQL (Key‑Value) Redis, DynamoDB High‑performance lookups, caching
NoSQL (Column‑Family) Cassandra, HBase Large‑scale write‑heavy, time‑series
NoSQL (Graph) Neo4j Relationships, social networks
Time‑Series InfluxDB, Prometheus Metrics, logs, monitoring

Polyglot Persistence

  • Use different databases for different use cases
  • PostgreSQL for user data (ACID)
  • Elasticsearch for search
  • Redis for cache
  • Cassandra for logs/analytics

Message Queue Patterns

Queue (Point‑to‑Point)

  • One sender, one receiver
  • Messages consumed once
  • FIFO ordering (optional)
  • Examples: RabbitMQ, SQS

Topic (Publish‑Subscribe)

  • One sender, multiple receivers
  • Multiple subscribers consume messages
  • Fan‑out pattern
  • Examples: Kafka, SNS, Pub/Sub

Message Broker Patterns

  • Event‑Driven Architecture – decoupled services communicate via events
  • Command Query Responsibility Segregation (CQRS) – separate read and write models
  • Event Sourcing – store state changes as events
  • Outbox Pattern – reliable event publishing from database
  • Dead Letter Queue (DLQ) – handle failed messages

Microservices Patterns

Service Registry

  • Service discovery
  • Services register themselves
  • Clients discover services dynamically
  • Examples: Eureka, Consul, Zookeeper

API Gateway

  • Single entry point for clients
  • Routing, authentication, rate limiting
  • Request aggregation
  • Examples: Kong, Nginx, AWS API Gateway

Circuit Breaker

  • Prevents cascading failures
  • Three states: Closed, Open, Half‑Open
  • Fails fast when service unhealthy
  • Examples: Hystrix, Resilience4j

Retry with Exponential Backoff

  • Retry failed requests
  • Increase delay between retries
  • Prevents overloading the service
  • Use jitter to avoid thundering herd

Distributed Tracing

  • Trace requests across services
  • Identify bottlenecks
  • Examples: Jaeger, Zipkin, OpenTelemetry

Health Check

  • Endpoint to check service health
  • Readiness (ready to serve traffic)
  • Liveness (running correctly)
  • Used by load balancers and K8s

Data Consistency Patterns

Strong Consistency

  • All reads see the latest write
  • Slower, lower availability
  • Examples: RDBMS, ZooKeeper, etcd

Eventual Consistency

  • Data may be temporarily inconsistent
  • Replicas eventually become consistent
  • High availability
  • Examples: DNS, Cassandra, DynamoDB

Two‑Phase Commit (2PC)

  • Distributed transaction ACID
  • Prepare + Commit phase
  • Blocking, not very scalable

Saga Pattern

  • Distributed transaction with compensating actions
  • Choreography or Orchestration
  • Eventual consistency
  • Each step has a compensating action for rollback

Database Sharding: Consistent Hashing

// Consistent hashing for shard distribution
class ConsistentHash {
    constructor(nodes, replicas) {
        this.replicas = replicas;
        this.ring = {};
        this.sortedKeys = [];
        for (let node of nodes) {
            this.addNode(node);
        }
    }

    addNode(node) {
        for (let i = 0; i < this.replicas; i++) {
            let hash = this.hash(node + ':' + i);
            this.ring[hash] = node;
            this.sortedKeys.push(hash);
        }
        this.sortedKeys.sort();
    }

    getNode(key) {
        let hash = this.hash(key);
        for (let h of this.sortedKeys) {
            if (hash <= h) return this.ring[h];
        }
        return this.ring[this.sortedKeys[0]];
    }

    hash(key) {
        let hash = 0;
        for (let i = 0; i < key.length; i++) {
            hash = (hash << 5) - hash + key.charCodeAt(i);
            hash |= 0;
        }
        return Math.abs(hash);
    }
}

Scalability Patterns

Horizontal Scaling (Scale‑Out)

  • Add more servers
  • Better for cloud environments
  • Fault‑tolerant
  • Requires load balancing

Vertical Scaling (Scale‑Up)

  • Add more resources to existing server
  • Limited by hardware
  • Single point of failure
  • Simpler to implement

Read‑Replicas

  • Spread read load across replicas
  • Improves read performance
  • Eventual consistency
  • Common for read‑heavy workloads

Write‑Sharding

  • Distribute writes across shards
  • Increases write capacity
  • Need to choose shard key carefully

API Design Patterns

REST

  • HTTP methods (GET, POST, PUT, DELETE)
  • Stateless
  • Resources and URIs
  • JSON/XML

GraphQL

  • Client‑specified queries
  • Single endpoint
  • Reduces over/under fetching
  • Complexity: resolver logic

gRPC

  • Protocol Buffers (Protobuf)
  • HTTP/2 (multiplexing)
  • Bi‑directional streaming
  • High performance

WebSocket

  • Full‑duplex real‑time communication
  • Persistent connection
  • Chat, live updates, gaming

Common System Design Questions

  • Design URL Shortener
  • Design Messaging System (WhatsApp, Slack)
  • Design Social Media Feed (Twitter, Instagram)
  • Design Video Streaming (YouTube, Netflix)
  • Design E‑Commerce Platform (Amazon)
  • Design File Storage (Dropbox, Google Drive)
  • Design Ride‑Sharing (Uber, Ola)
  • Design Search Engine
  • Design Distributed Cache
  • Design Rate Limiter
📌 Quick Reference
CAP Theorem: Consistency, Availability, Partition Tolerance (choose 2)
Load Balancing: Round Robin, Least Connections, IP Hash, Weighted
Caching: Cache‑Aside, Read‑Through, Write‑Through, Write‑Behind
Database: Master‑Slave, Sharding (hash/range/directory), Polyglot Persistence
Message Queue: Queue (point‑to‑point), Topic (pub‑sub)
Microservices: Service Registry, API Gateway, Circuit Breaker, Retry
Consistency: Strong (RDBMS), Eventual (NoSQL), Saga (distributed transactions)
Scaling: Horizontal (add servers), Vertical (add resources), Read Replicas, Sharding
← Back to All Cheatsheets