{"id":380,"date":"2026-01-01T00:00:00","date_gmt":"2026-01-01T00:00:00","guid":{"rendered":"https:\/\/springgreen-curlew-885344.hostingersite.com\/blog\/system-design-cheat-sheet\/"},"modified":"2026-06-19T05:46:38","modified_gmt":"2026-06-19T05:46:38","slug":"system-design-cheat-sheet","status":"publish","type":"post","link":"https:\/\/lastroundai.com\/blog\/system-design-cheat-sheet","title":{"rendered":"System Design Cheat Sheet: The Tables I’d Print Before an Interview"},"content":{"rendered":"

This is the reference card, not the tutorial. Lookup tables for latency, datastore selection, and scaling patterns. Skim the morning of, not the night before. If you need the full process walkthrough, the minute-by-minute guide<\/a> covers that.<\/p>\n

Five questions to ask in minute one<\/h2>\n
    \n
  1. What’s in scope? What’s explicitly out?<\/li>\n
  2. What’s the scale? (DAU, peak QPS, average payload size, read\/write ratio.)<\/li>\n
  3. What’s the latency target? (p50, p99, separate per operation if reads and writes differ.)<\/li>\n
  4. What consistency model? (Strong, eventual, read-your- writes, monotonic.)<\/li>\n
  5. What region setup? Single-region or multi-region?<\/li>\n<\/ol>\n

    Latency numbers worth memorising<\/h2>\n

    The Jeff Dean “numbers every programmer should know” list, updated for current hardware:<\/p>\n

    \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
    Operation<\/th>\nLatency<\/th>\nWhat you can do in that time<\/th>\n<\/tr>\n<\/thead>\n
    L1 cache reference<\/td>\n0.5 ns<\/td>\n~<\/td>\n<\/tr>\n
    L2 cache reference<\/td>\n7 ns<\/td>\n14x L1<\/td>\n<\/tr>\n
    Main memory reference<\/td>\n100 ns<\/td>\n200x L1<\/td>\n<\/tr>\n
    Send 1KB over 1 Gbps network<\/td>\n10 \u03bcs<\/td>\n100x main memory<\/td>\n<\/tr>\n
    SSD random read<\/td>\n150 \u03bcs<\/td>\n15x network 1KB<\/td>\n<\/tr>\n
    Read 1MB sequentially from SSD<\/td>\n1 ms<\/td>\nn\/a<\/td>\n<\/tr>\n
    Disk seek (spinning, rare now)<\/td>\n10 ms<\/td>\n10x SSD sequential<\/td>\n<\/tr>\n
    Same-region datacentre round-trip<\/td>\n500 \u03bcs<\/td>\nn\/a<\/td>\n<\/tr>\n
    Cross-region (US-East to US-West)<\/td>\n70 ms<\/td>\n140x same-region<\/td>\n<\/tr>\n
    Cross-continent (US to EU)<\/td>\n150 ms<\/td>\nn\/a<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Two implications that come up in interviews: (1) a request that touches three services in series, each calling its own DB, can’t beat ~5ms even in the happy path. (2) Anything cross-region in the hot path is a design smell. Cache aggressively or shard by region.<\/p>\n

    Pick the right datastore<\/h2>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    Workload<\/th>\nPick<\/th>\nWhy<\/th>\n<\/tr>\n<\/thead>\n
    Transactional, joins, ACID<\/td>\nPostgres \/ MySQL<\/td>\nMature, predictable, you know it<\/td>\n<\/tr>\n
    High write throughput, append-only<\/td>\nCassandra \/ Scylla<\/td>\nLinear write scaling, tunable consistency<\/td>\n<\/tr>\n
    Key-value, sub-ms reads<\/td>\nRedis \/ DynamoDB<\/td>\nMemory or SSD-backed key-value<\/td>\n<\/tr>\n
    Time-series \/ metrics<\/td>\nTimescaleDB \/ InfluxDB<\/td>\nTime-partitioned compression<\/td>\n<\/tr>\n
    Full-text search<\/td>\nElasticsearch \/ OpenSearch<\/td>\nInverted index, relevance scoring<\/td>\n<\/tr>\n
    Graph traversal<\/td>\nNeo4j \/ Neptune<\/td>\nNative graph storage, Cypher<\/td>\n<\/tr>\n
    Vector similarity (LLM apps)<\/td>\nPinecone \/ pgvector \/ Qdrant<\/td>\nANN index for embeddings<\/td>\n<\/tr>\n
    Object \/ file blobs<\/td>\nS3 \/ GCS<\/td>\nCheap, durable, range reads<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Pick the workload first. The datastore follows. The reverse order is how candidates end up justifying MongoDB for a join-heavy workload.<\/p>\n

    Scaling patterns by problem<\/h2>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    Problem<\/th>\nPattern<\/th>\nWatch out for<\/th>\n<\/tr>\n<\/thead>\n
    Read-heavy<\/td>\nRead replicas + cache<\/td>\nCache stampede on cold start<\/td>\n<\/tr>\n
    Write-heavy<\/td>\nSharding by user_id \/ hash<\/td>\nHot shards on celebrity accounts<\/td>\n<\/tr>\n
    Bursty traffic<\/td>\nQueue + async workers<\/td>\nConsumer lag, dead-letter handling<\/td>\n<\/tr>\n
    Cross-region reads<\/td>\nCDN + edge cache<\/td>\nCache invalidation lag<\/td>\n<\/tr>\n
    Fanout (timeline, notifications)<\/td>\nFan-out-on-write + pull for whales<\/td>\nMaterialise lag, follower-count spikes<\/td>\n<\/tr>\n
    Idempotent writes<\/td>\nClient-generated idempotency key<\/td>\nKey cardinality, key TTL<\/td>\n<\/tr>\n
    Long-running jobs<\/td>\nJob queue with status polling<\/td>\nStatus table contention<\/td>\n<\/tr>\n
    Rate limiting<\/td>\nToken bucket in Redis<\/td>\nDistributed clock skew<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    CAP one-liner the panel actually wants<\/h2>\n

    “Under network partition, you pick between consistency and availability. In practice, you pick eventual consistency for most user-facing reads and strong consistency only for the operations where stale data corrupts something: payment confirmation, inventory count, account balance. For everything else, eventual is cheaper, faster, and fine.”<\/p>\n

    That’s the answer. Don’t quote the CAP paper. Don’t draw the triangle.<\/p>\n

    Failure-mode checklist for the last 5 minutes<\/h2>\n

    Walk the panel through each:<\/p>\n