Cheat Sheets — Last-Mile Quick Reference¶

Dense, scannable reference tables for the night-before review. Read top to bottom in 30–45 minutes. Everything here is approximate by design — interviewers want orders of magnitude and correct reasoning, not memorized decimals.

1. Latency Numbers Every Engineer Should Know¶

Round figures (modern server, ~2020s hardware). Memorize the ratios, not the digits.

Key ratios: RAM is ~100× L1. SSD is ~1000× RAM. Network DC round-trip is ~5× SSD read. Cross-continent is ~300× DC round-trip. Disk seek ≈ cross-continent round-trip.

2. Big-O Complexity — Data Structures & Algorithms¶

Data structure operations (average / worst)¶

* amortized; a single append that triggers regrow is O(n). † given the node pointer.

Sorting¶

Go standard library specifics¶

3. Capacity Estimation Cheatsheet¶

Time constants¶

QPS math¶

• Avg QPS = daily requests / 86,400. So 1M req/day ≈ 12 QPS. 1B req/day ≈ 12k QPS.
• Peak QPS ≈ 2–3× average (rule of thumb). Some bursty systems: 10×.
• DAU × actions/user/day → daily requests. e.g. 10M DAU × 20 actions = 200M req/day ≈ 2.3k avg QPS, ~5–7k peak.

Powers of two ↔ storage¶

Typical record sizes (estimation anchors)¶

Worked example: 1B orders/year × 1 KB = 1 TB/year raw. With indexes + replication (×3) + overhead → budget ~5 TB/year. Storage is cheap; design for retention/archival.

4. PostgreSQL Isolation Levels vs Anomalies¶

✗ = prevented, ✓ = possible. PostgreSQL is stricter than the SQL standard (no dirty reads even at Read Committed; "Repeatable Read" is actually snapshot isolation).

* PostgreSQL treats Read Uncommitted as Read Committed — dirty reads never occur.

Anomaly definitions: - Dirty read — read uncommitted data from another txn. - Non-repeatable read — re-read a row, value changed (committed update). - Phantom read — re-run a query, new rows appear (committed insert). - Serialization anomaly — concurrent commits produce a result no serial order could.

Senior notes: Repeatable Read & Serializable can throw 40001 serialization_failure → app must retry. Serializable uses SSI (predicate locks), not blocking, so it scales surprisingly well for OLTP but raises abort rate under contention. Read Committed re-reads the latest snapshot per statement — beware lost updates; use SELECT ... FOR UPDATE or INSERT ... ON CONFLICT.

5. Kafka Quick Reference¶

Producer acks¶

Durability config¶

• ISR (In-Sync Replicas): replicas caught up with the leader. Leader + ISR define the durable set.
• min.insync.replicas: with acks=all, write fails if ISR count drops below this. Set to 2 with RF=3 → survive 1 broker loss, still reject writes when too few replicas (no silent under-replication).
• Golden durability combo: replication.factor=3, min.insync.replicas=2, acks=all, unclean.leader.election.enable=false.

Delivery semantics¶

Partitions & consumer groups¶

• More partitions = more parallelism, but more open files, more rebalance cost, higher end-to-end latency, more controller load. Tune up when consumer lag grows and consumers are CPU/IO-bound — not preemptively.
• Max useful consumers in a group = partition count. Extra consumers sit idle.
• Ordering is per-partition only. Need ordering? Key by entity id (e.g. order_id) so all events for one entity land on one partition.
• A partition is consumed by exactly one consumer in a group at a time.
• Rebalances pause consumption — prefer cooperative/incremental rebalancing (CooperativeStickyAssignor).

6. HTTP Status Codes That Matter¶

409 vs 422: 409 = conflict with current resource state (versioning, uniqueness). 422 = the payload itself fails business validation. 429 vs 503: 429 = this client exceeded its quota. 503 = the server can't serve anyone right now.

7. HTTP Method Semantics¶

• Safe = no server-state change. Idempotent = N identical calls ≡ 1 call's effect.
• * PATCH is not guaranteed idempotent, but can be designed to be (e.g. set-absolute-value semantics).
• Senior tip: Make POST idempotent with an idempotency key header when retries are possible (payments, order creation).

8. Go Concurrency Quick Patterns¶

// Worker pool
jobs := make(chan Job); results := make(chan Result)
for i := 0; i < numWorkers; i++ {
    go func() { for j := range jobs { results <- process(j) } }()
}

// Fan-out / fan-in
// fan-out: launch N goroutines reading from one input chan
// fan-in: merge N output chans into one via a sync.WaitGroup + single out chan

// errgroup — bounded, first-error-cancels-context
g, ctx := errgroup.WithContext(ctx)
g.SetLimit(8)                       // bound concurrency (1.23+)
for _, item := range items {
    item := item
    g.Go(func() error { return work(ctx, item) })
}
err := g.Wait()                     // returns first non-nil error

// Semaphore (bound concurrency without a pool)
sem := make(chan struct{}, maxConcurrent)
sem <- struct{}{}                   // acquire
go func() { defer func() { <-sem }(); work() }()

// select with timeout
select {
case res := <-ch:        use(res)
case <-time.After(2*time.Second): return ErrTimeout
case <-ctx.Done():       return ctx.Err()
}

// Pipeline cancellation: always pass ctx; check ctx.Done() in long loops.

Rules: the goroutine that creates a channel owns closing it; never close from the receiver side; for range ch exits when the channel is closed; a nil channel blocks forever (useful to disable a select case).

9. Go Performance Checklist¶

Allocation reduction¶

• Preallocate: make([]T, 0, n), make(map[K]V, n).
• Reuse buffers with sync.Pool (for short-lived, frequently-allocated objects).
• strings.Builder instead of + in loops; bytes.Buffer for []byte.
• Pass small structs by value; avoid pointers that force heap escape.
• Avoid interface{}/boxing in hot paths; watch escape analysis: go build -gcflags=-m.
• Prefer slices of structs over slices of pointers (better cache locality, fewer allocs).

pprof commands¶

go test -bench=. -benchmem -cpuprofile cpu.out -memprofile mem.out
go tool pprof cpu.out          # interactive; top, list <fn>, web
go tool pprof -http=:8080 cpu.out
# live server (import _ "net/http/pprof")
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30   # CPU
go tool pprof http://localhost:6060/debug/pprof/heap                 # heap
go tool pprof http://localhost:6060/debug/pprof/allocs               # all allocs
curl localhost:6060/debug/pprof/goroutine?debug=2                    # goroutine dump
go tool trace trace.out        # scheduler/GC latency analysis

GC / memory tuning¶

• GOGC (default 100): GC triggers when heap grows 100% since last GC. Higher (e.g. 200) = less CPU, more RAM. GOGC=off disables (dangerous).
• GOMEMLIMIT (1.19+): soft memory cap, e.g. GOMEMLIMIT=4GiB. Use it to avoid OOM-kills in containers; set it below the container limit (~80–90%). Pair with GOGC=off for a hard-cap-driven GC strategy in memory-constrained pods.
• GOMAXPROCS: set to container CPU quota (use automaxprocs lib) or you'll oversubscribe and thrash.

10. Redis Data Structures & Use Cases¶

Senior notes: Redis is single-threaded for commands — avoid O(n) commands (KEYS, big SMEMBERS) on large keys; use SCAN. Set TTLs to bound memory; pick an eviction policy (allkeys-lru for cache, noeviction for queues). For distributed locks across nodes, plain SET NX is fine for most cases; Redlock only when you truly need multi-master safety (and understand its caveats).

11. AWS Service Cheat-Map¶

E-commerce mapping (this role): ALB → ECS/Fargate Go services → RDS Aurora Postgres + ElastiCache Redis; MSK for the event backbone; S3 for assets/exports; SNS+SQS or EventBridge for fan-out notifications; Secrets Manager for credentials; CloudWatch + X-Ray for observability.

12. The Nines (Availability → Downtime)¶

Senior note: Each nine roughly costs an order of magnitude more (redundancy, multi-AZ → multi-region, automation). Tie targets to an error budget: 99.9% = ~43 min/month of allowed downtime to spend on risky deploys.

13. gRPC vs REST — Quick Decision¶

Rule of thumb: gRPC inside the mesh (Go service ↔ Go service), REST at the edge (public API, partner integrations, mobile).

14. SQL EXPLAIN — Scan & Join Types (PostgreSQL)¶

Scan types (cheapest → most expensive, context-dependent)¶

Join types¶

What to look for in EXPLAIN ANALYZE¶

• rows estimate vs actual rows wildly off → stale stats; run ANALYZE.
• Seq Scan on a big table with a selective WHERE → missing/unused index.
• Rows Removed by Filter high → index not selective enough; consider composite/partial index.
• loops=N large on a Nested Loop → likely the wrong join strategy (bad estimates).
• Sort / Hash spilling to disk (external merge Disk: …kB) → raise work_mem or reduce rows earlier.
• Always use EXPLAIN (ANALYZE, BUFFERS) to see real I/O, and BUFFERS to spot cache misses.