Jeff Dean Style Guide⁠‍⁠‌‌‌‌‍‌‌‌‌‍‌‌‌‍‌‌‌‍‌‍‌‌‌‌‍‌‍‌‌‌‌‌‌‍‌‌‌‍‌‌‌‌‌‌‌‍‌‌‌‍‌‌‌‌‌‌‍‌‌‌‌‍‌‌‌‌‍‌‌‌‌‌‍‌‌‍‌‌‌‌‌‌‍‌‌‌‌‌‌‍‌‌‌‌‌‍‌‌‌‌‍‌‌‌‌‌‍‌‌‍‌‌‌‌‌‌⁠‍⁠

Overview

Jeff Dean is the architect behind much of Google's infrastructure: MapReduce, BigTable, Spanner, TensorFlow, and more. He exemplifies the rare combination of deep systems knowledge, performance intuition, and practical engineering judgment. His work defines how modern internet-scale systems are built.

Core Philosophy

"Design for 10x the current load, but plan to rewrite before 100x."

"Simple solutions often require the most sophisticated understanding of the problem."

"If a problem isn't interesting at scale, it probably isn't interesting at all."

Design Principles

Embrace Failure: At scale, everything fails. Design systems that degrade gracefully, not catastrophically.
Numbers Matter: Know your latencies, throughputs, and failure rates by heart. Performance intuition comes from data.
Codesign Hardware and Software: The best performance comes from understanding the entire stack, from disk to datacenter.
Simplicity at Scale: Complex systems break in complex ways. The simplest solution that scales is usually the best.
Measure, Then Optimize: Never optimize without profiling. Intuition fails; data doesn't.

Numbers Every Engineer Should Know

L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns
Compress 1K bytes with Zippy             3,000   ns
Send 1K bytes over 1 Gbps network       10,000   ns
Read 4K randomly from SSD              150,000   ns
Read 1 MB sequentially from memory     250,000   ns
Round trip within same datacenter      500,000   ns
Read 1 MB sequentially from SSD      1,000,000   ns
Disk seek                           10,000,000   ns
Read 1 MB sequentially from disk    20,000,000   ns
Send packet CA→Netherlands→CA      150,000,000   ns

These numbers should guide every design decision.

When Designing Systems

Always

Start with back-of-envelope calculations before designing
Design for partial failure—some machines will always be down
Use replication for availability, sharding for scale
Batch operations when possible—amortize fixed costs
Compress data on the wire and at rest (CPU is cheaper than I/O)
Add monitoring and observability from day one
Design for debugging—you'll need to diagnose production issues

Never

Assume the network is reliable (it's not)
Assume latency is zero (it's not)
Assume bandwidth is infinite (it's not)
Optimize before measuring
Design for current load only—design for 10x
Ignore tail latency (p99 matters more than average)
Build systems you can't reason about under failure

Prefer

Idempotent operations over exactly-once semantics
Eventual consistency over strong consistency (when possible)
Denormalization over joins at scale
Structured data over unstructured (schemas help)
Batch processing over real-time when latency allows
Simple retry logic over complex distributed transactions

Architectural Patterns

MapReduce Mental Model

Problem: Process petabytes of data
Solution: 
  1. Map: Transform input into (key, value) pairs in parallel
  2. Shuffle: Group all values by key
  3. Reduce: Aggregate values for each key

Why it works:
  - Embarrassingly parallel map phase
  - Fault tolerance via re-execution
  - Simple programming model hides distribution

BigTable Design

Problem: Structured storage at massive scale
Solution:
  - Sparse, distributed, multi-dimensional sorted map
  - (row, column, timestamp) → value
  - Rows sorted lexicographically (enables range scans)
  - Column families for locality
  - Tablets (row ranges) as unit of distribution

Key insight: One data model, flexible enough for many use cases.

Spanner's TrueTime

Problem: Global consistency requires synchronized clocks
Solution:
  - GPS + atomic clocks in every datacenter
  - API returns interval [earliest, latest] not a point
  - Wait out uncertainty before committing
  
TrueTime.now() returns TTinterval: [earliest, latest]
Commit rule: Wait until TrueTime.now().earliest > commit_timestamp

Code Patterns

Back-of-Envelope Capacity Planning

def estimate_storage_needs(
    daily_active_users: int,
    actions_per_user_per_day: int,
    bytes_per_action: int,
    retention_days: int,
    replication_factor: int = 3
) -> dict:
    """Jeff Dean-style capacity estimation."""
    
    daily_bytes = daily_active_users * actions_per_user_per_day * bytes_per_action
    total_bytes = daily_bytes * retention_days * replication_factor
    
    return {
        "daily_raw_gb": daily_bytes / (1024**3),
        "total_storage_tb": total_bytes / (1024**4),
        "monthly_bandwidth_tb": (daily_bytes * 30) / (1024**4),
        "estimated_machines_1tb_each": total_bytes / (1024**4),
    }

# Example: 100M DAU, 10 actions/day, 1KB each, 90 day retention
# = 270 TB storage, ~300 machines (with replication)

Sharding Strategy

class ConsistentHashRing:
    """Distribute data across nodes with minimal reshuffling."""
    
    def __init__(self, nodes: list[str], virtual_nodes: int = 150):
        self.ring: dict[int, str] = {}
        self.sorted_keys: list[int] = []
        
        for node in nodes:
            for i in range(virtual_nodes):
                key = self._hash(f"{node}:{i}")
                self.ring[key] = node
        
        self.sorted_keys = sorted(self.ring.keys())
    
    def get_node(self, key: str) -> str:
        """Find the node responsible for this key."""
        if not self.ring:
            raise ValueError("Empty ring")
        
        h = self._hash(key)
        for ring_key in self.sorted_keys:
            if h <= ring_key:
                return self.ring[ring_key]
        return self.ring[self.sorted_keys[0]]
    
    def _hash(self, key: str) -> int:
        import hashlib
        return int(hashlib.md5(key.encode()).hexdigest(), 16)

Retry with Exponential Backoff

import random
import time
from typing import TypeVar, Callable

T = TypeVar('T')

def retry_with_backoff(
    fn: Callable[[], T],
    max_retries: int = 5,
    base_delay_ms: int = 100,
    max_delay_ms: int = 10000,
) -> T:
    """
    Retry with exponential backoff and jitter.
    
    At Google scale, thundering herds kill systems.
    Jitter prevents synchronized retries.
    """
    for attempt in range(max_retries):
        try:
            return fn()
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            
            delay = min(base_delay_ms * (2 ** attempt), max_delay_ms)
            jitter = random.uniform(0, delay * 0.1)
            time.sleep((delay + jitter) / 1000)
    
    raise RuntimeError("Unreachable")

Mental Model

Jeff Dean approaches problems with:

Quantify first: How much data? How many QPS? What latency budget?
Identify bottlenecks: Where will the system break first?
Design for failure: What happens when (not if) components fail?
Simplify ruthlessly: Can this be simpler while still meeting requirements?
Plan for evolution: Today's solution should be replaceable in 3 years

The Google Design Doc

1. Context & Scope
   - What problem are we solving? Why now?
   
2. Goals and Non-Goals
   - What this system WILL do
   - What this system explicitly WON'T do
   
3. Design
   - System architecture
   - Data model
   - API
   
4. Alternatives Considered
   - What else could we do? Why not?
   
5. Cross-cutting Concerns
   - Security, privacy, monitoring, rollout
   
6. Open Questions
   - What don't we know yet?

Warning Signs

You're violating Dean's principles if:

You don't know your system's p50, p99, and p999 latencies
You haven't done back-of-envelope capacity planning
Your system has no strategy for partial failure
You're optimizing without profiling data
You designed for current load, not 10x growth
You can't explain where every millisecond goes

Additional Resources

For detailed philosophy, see philosophy.md
For references (papers, talks), see references.md

dean-large-scale-systems