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 nsThese 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 distributionBigTable 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_timestampCode 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