Fast by Design

Performance Engineering for Java Systems, from the JVM to the Wire.

This book targets senior Java developers who have optimized something and made it worse, added an index and slowed down writes, or tuned a thread pool and increased latency. Never explains what Big-O notation is from scratch. Never defines what a database index is for a beginner. The reader has a production system with a performance problem. This book gives them the tools to find it, measure it, and fix it without guessing.

Every chapter uses the same domain: a high-traffic content delivery and analytics platform. Article ingestion, full-text search, read-heavy content serving, real-time view counting, recommendation ranking, and usage analytics aggregation. The domain is deliberately read-heavy and write-mixed, which stresses every layer the book covers: JVM allocation, cache hit rates, PostgreSQL read and write paths, serialization throughput, and network payload size.

Four opinions run through every chapter:

Measure before you change anything. An optimization without a before-and-after benchmark is a guess with extra steps. Every chapter that introduces an optimization technique requires a JMH benchmark, a Locust result, or a PostgreSQL execution plan comparison before and after the change. Opinion without a number is not performance engineering.

The bottleneck is almost never where you think it is. Senior engineers consistently misidentify bottlenecks because they optimize what they understand rather than what the profiler shows. CPU flame graphs, allocation profilers, and query execution plans exist precisely because intuition fails at the layer below the one you are watching. This book treats profiling as the first step of every investigation, not a last resort.

Algorithms and data structure choices outperform micro-optimizations by orders of magnitude. Replacing ArrayList with ArrayDeque for a queue is a micro-optimization. Replacing an O(n) linear scan with an O(1) hash lookup on a hot path serving 10k requests per second is architectural. The book treats algorithmic complexity as a performance engineering discipline, not a theoretical exercise.

PostgreSQL performance is application code performance. The query the ORM generates, the index the schema is missing, the transaction boundary that holds a lock too long: these are application decisions with database consequences. PostgreSQL is not a black box to hand queries to. It is a component whose execution plan is as readable and as tunable as application code.

Code examples use Java 21 and Spring Boot 3. Benchmarks use JMH. Profiling uses async-profiler. Database optimizations use PostgreSQL with full EXPLAIN ANALYZE output. Load testing uses Locust. Observability uses OpenTelemetry, Prometheus, and Grafana. Infrastructure runs on Kubernetes with Docker. Every chapter follows the same structure: the symptom, the cause, the benchmark or baseline, the fix, the proof, and the trade-off.

This book was generated using AI assistance.