This is a review of System Design Interview Volume 2 by Alex Xu (co-authored with Sam), a 400-page book that is the #1 Amazon US bestseller in computer science at the time of recording. The reviewer, Gergely Orosz, is the author of The Pragmatic Engineer newsletter and has four years of experience building payment systems at Uber. He evaluates the book both as a general system design resource and specifically through the lens of the payments chapter, which he reviewed before publication.
How Volume 1 and Volume 2 compare
Volume 1 is ~300 pages with 16 chapters, each a case study; Volume 2 is ~400 pages with 13 chapters, each covering a larger, more complex system.
Volume 2 is co-authored by Sam, a former colleague of Alex Xu’s at Zynga, who rewrote or substantially revised chapters after Alex drafted them.
Each chapter in Volume 2 was thoroughly reviewed by experienced engineers, staff engineers, and directors at well-known companies.
The chapter topics are: proximity service (Nearby Friends), Google Maps, distributed message queue, metrics monitoring, ad click events, wholesale reservation, distributed email service, S3-like object storage, real-time gaming leaderboard, payment system, digital wallet, and stock exchange.
The four-part structure of a system design interview (and each chapter)
Part 1 — Understanding the problem and scoping: Clarify the problem, ask questions, and make constraints clear. Jumping straight to a solution earns no bonus points; the goal is to confirm you’re solving the right problem.
Part 2 — Proposing a high-level solution and getting buy-in: Present a high-level design, discuss it with the interviewer, and iterate until both parties are aligned. This mirrors real-world practice where you confirm constraints and trade-offs before committing to an architecture.
Part 3 — Design deep dive: Either the interviewer or candidate selects specific areas to explore in depth. This is where domain knowledge, vocabulary, and real experience matter most. The books list relevant topics, but candidates may also need resources like the System Design Primer or Designing Data-Intensive Applications.
Part 4 — Wrap-up: Identify real-world improvements you’d make if this were a production system — monitoring, alerting, future bottlenecks, scaling concerns. The goal is to signal that you understand system design is never truly finished.
Deep dive into the payments chapter (Chapter 11)
Scoping questions the book suggests: What kind of system (e.g., e-commerce like Amazon)? What payment methods (credit cards, wallets, cash)? Do we handle credit card processing ourselves (in-house like Visa, or outsource)? Do we store credit card data (usually out of scope unless the role is payments engineering)? Global or local requirements? Expected transaction volume and user count? Pay-in, pay-out, or both?
Additional real-world questions the reviewer would ask: What SLAs and latencies are acceptable? Are credit card authorizations blocking for the customer? Is fraud in scope? What about reconciliation flows and chargebacks?
High-level design presented in the book: Buyers interact with a website; the system has a payment service, a ledger, a wallet, and a payment executor. Payment events go into the payment service, which stores them in a database. Communication with payment service providers (PSPs) like Stripe, Adyen, Mastercard, Apple Pay, Google Pay is mediated through a dedicated layer that logs all API requests and responses. Responses update the wallet (credits/debits) and the ledger.
The reviewer notes this design is accurate and matches how Uber’s payment system was built. Concepts like the ledger and the distinction between a wallet and a ledger are non-trivial and well-covered.
The book explains the double-entry ledger system, proposes APIs, and covers data models for the payment service and ledger.
Deep dive topics covered:
Reconciliation: The book includes a reconciliation section, which the reviewer found valuable because his own team at Uber lost money during an outage due to reconciliation issues early on. Reconciliation involves comparing your ledger against settlement files sent by PSPs (typically via SFTP/FTP in legacy formats like fixed-width files or even Excel). Discrepancies arise frequently, and the stored API request/response database serves as a source of truth to investigate them. Common real-world challenges include refunds, chargebacks, and accounts deleted after charges.
Failed payments: The book covers retry queues and dead letter queues for non-retriable failures. The reviewer adds that real-world details like retry strategies (linear vs. exponential backoff) and “dunning” (bulk retry of failed payment instruments) are domain-specific and not covered, but reasonably so given space constraints. Dunning at scale can cause significant system load; there are startups built entirely around dunning-as-a-service.
Other deep dive areas: Exactly-once semantics, idempotency, and consistency models.
Wrap-up topics listed: Monitoring, alerting, debugging tools, currency exchange, geographic considerations, cash payments, Google/Apple Pay integration — each large enough to fill 50+ pages on its own.
The reviewer shares a real-world example: Uber’s cash payments team processed $1 billion/year with 1.5 engineers. At one point, ~40% of Uber’s transactions were cash. Challenges included fraud, physical safety (drivers without change for angry customers), and collecting commissions from cash-heavy drivers who owed money and had to physically drive to an office to pay.
Chapter summaries and mind maps
Each chapter ends with a mind map summarizing functional and non-functional aspects, reinforcing the structured approach.
The reviewer identifies three keys to a strong system design interview: (1) dynamic back-and-forth conversation with the interviewer, (2) past experience or domain knowledge, and (3) structured thinking — starting high-level, diving deep, and being able to zoom back out.
Overall assessment
The book is well-written, well-researched, and balances conciseness with detail. Some domain-specific details (e.g., dunning, payment-specific fraud) are necessarily omitted to keep chapters manageable.
The content is more software-engineering-general than domain-specific, covering consistency, idempotency, retries, and other broadly applicable concepts.
The reviewer wishes he had read the payments chapter before joining Uber — it would have accelerated his learning significantly.
He considers this book (together with Volume 1, which covers different topics) the best available resource for system design interview preparation.
His advice for using the book effectively: Don’t read passively. Pause at each chapter, research the domain, sketch your own design, then compare with the book’s approach. Use the references. Focus on understanding trade-offs and use cases rather than memorizing solutions, so you can adapt your approach to whatever problem the interviewer presents.
