Fundamentals — Cheat Sheet

Horizontal vs Vertical Scaling

// Vertical scaling example
// Before: 4 CPU cores, 16 GB RAM → handles 1,000 req/s
// After:  32 CPU cores, 128 GB RAM → handles ~6,000 req/s

// Pros:
//  - Zero code changes
//  - No distributed-systems complexity
//  - Single data copy (no consistency issues)

// Cons:
//  - Hardware ceiling (biggest EC2 = 448 vCPU / 24 TB RAM)
//  - Single point of failure
//  - Downtime for upgrades (usually)
//  - Cost grows faster than linearly

CAP Theorem

// CAP visualisation
//
//        Consistency (C)
//           /    \
//          /      \
//     CP systems   CA systems
//    (HBase,       (single-node
//     MongoDB,      RDBMS — not
//     etcd)         distributed)
//          \      /
//           \    /
//     Partition Tolerance (P)
//           /    \
//          /      \
//     AP systems
//    (Cassandra, DynamoDB,
//     CouchDB, Riak)
//          \
//      Availability (A)

// Network partitions are INEVITABLE in distributed systems
// → the real choice is C vs A during a partition.

Load Balancing

// L4 load balancer — TCP level
// Client → LB (picks backend by IP:port) → Backend
// Fast, simple, but no content awareness

// L7 load balancer — HTTP level (NGINX example)
upstream api_servers {
    least_conn;                    # algorithm
    server api1.internal:8080;
    server api2.internal:8080;
    server api3.internal:8080;
}

upstream static_servers {
    server cdn1.internal:80;
    server cdn2.internal:80;
}

server {
    listen 443 ssl;

    # Path-based routing (L7 feature)
    location /api/ {
        proxy_pass http://api_servers;
    }
    location /static/ {
        proxy_pass http://static_servers;
    }
}

Caching Strategies

// Cache-aside with Redis + Spring Boot
@Service
public class ProductService {
    private final RedisTemplate<String, Product> redis;
    private final ProductRepository repo;

    public Product getProduct(String id) {
        String key = "product:" + id;

        // 1. Check cache
        Product cached = redis.opsForValue().get(key);
        if (cached != null) return cached;           // cache HIT

        // 2. Cache miss → read from DB
        Product product = repo.findById(id)
            .orElseThrow(() -> new NotFoundException(id));

        // 3. Populate cache with TTL
        redis.opsForValue().set(key, product, Duration.ofMinutes(30));
        return product;
    }

    public Product updateProduct(String id, ProductUpdateDTO dto) {
        Product updated = repo.save(/* ... */);
        redis.delete("product:" + id);   // invalidate cache
        return updated;
    }
}

Content Delivery Network (CDN)

// CDN request flow
//
//  User (Mumbai) → DNS → CDN Edge (Mumbai PoP)
//     │
//     ▼
//  Cache HIT? ──yes──→ Serve from edge (< 20ms)
//     │
//     no
//     │
//     ▼
//  Fetch from Origin (us-east-1) → Cache at edge → Serve user
//
// Subsequent requests from Mumbai region → served from edge cache

// Cache-Control headers control CDN behaviour
Cache-Control: public, max-age=86400, s-maxage=604800
//  max-age=86400    → browser caches for 1 day
//  s-maxage=604800  → CDN caches for 7 days
//  public           → CDN is allowed to cache this

// Invalidation
// POST /invalidation { paths: ["/images/*", "/css/main.css"] }

DNS & Domain Resolution

// DNS resolution step by step
//
// 1. Browser cache (Chrome: chrome://net-internals/#dns)
// 2. OS cache (macOS: scutil --dns)
// 3. Recursive resolver (ISP / 8.8.8.8 / 1.1.1.1)
//    └─→ 4. Root server (.) → returns .com TLD server
//    └─→ 5. TLD server (.com) → returns authoritative NS for example.com
//    └─→ 6. Authoritative NS → returns A record: 93.184.216.34
// 7. Response cached at resolver (TTL = 300s)
// 8. Response returned to OS → browser → connection to IP

// dig command to inspect DNS
$ dig api.example.com +trace
// Shows each hop: root → .com → example.com → A record

// Common record types:
// A      → IPv4 address          (api.example.com → 1.2.3.4)
// AAAA   → IPv6 address
// CNAME  → alias to another name (www → api.example.com)
// MX     → mail server
// TXT    → verification, SPF, DKIM
// NS     → nameserver delegation

Latency vs Throughput

// Latency numbers every programmer should know (2024)
//
// Operation                    | Latency
// ─────────────────────────────────────────
// L1 cache reference           |     1 ns
// L2 cache reference           |     4 ns
// RAM reference                |   100 ns
// SSD random read              |   100 μs
// HDD seek                     | 4,000 μs  (4 ms)
// Network: same datacenter     |   500 μs  (0.5 ms)
// Network: cross-region        |   ~80 ms
// Network: cross-continent     |  ~150 ms
// Redis GET                    |   ~0.5 ms
// PostgreSQL simple query      |   ~2 ms
// S3 GET (same region)         |   ~20 ms
// External API call            |  50-500 ms

// Rule of thumb: memory is 1000x faster than disk,
// same-DC network is 100x faster than cross-region.