Architectural Trade‑offs: Why eBay and Amazon Avoid Distributed Transactions and Embrace BASE

System architects must balance conflicting requirements, and as systems grow, traditional wisdom is challenged; eBay chose to avoid transactions to improve overall scalability and performance.

In an interview, Dan Pritchard explained why eBay does not use cross‑resource or distributed transactions, citing dependency creation, client failures, and the need to design for failure.

He noted that application‑level transactions have inherent problems; managing resource lifecycles introduces errors, and declarative transactions act as a blunt tool assuming equal importance of all database operations.

The decision to use transactions depends on scalability and availability goals; high‑throughput systems cannot afford distributed transactions, and architects must trade constraints without a simple formula.

Regarding atomicity for a “Place bid” operation, eBay treats bidding as a low‑contention insert into a sub‑table and relies on BASE—basic availability, soft state, eventual consistency—relaxing consistency at request end and using asynchronous events with fallback server‑side transactions.

Advice to other architects emphasizes that scaling a system does not add resources to a design meant for small scale; one should abandon ACID and distributed transactions, look for opportunities to relax constraints, and design for splitting using BASE.

Werner Vogels referenced the CAP theorem, explaining that large distributed systems must choose between consistency and availability when partition tolerance is inevitable, placing responsibility on developers to handle delayed writes.

Similar practices are observed at Windows Live, where developers complain about error recovery being shifted from transactions to application code.

Many large websites independently arrived at these conclusions, indicating that the trade‑offs faced by eBay and Amazon will become relevant to enterprise systems as they scale.