eBay's Architectural Generations
eBay rewrote its core platform several times across its first decade, each time because the previous generation had hit a limit that could not be tuned away.
The generations, as described publicly by its architects
V1 (1995–1997): a Perl monolith. A single developer's system. It worked until the traffic did not fit.
V2 (1997–2002): C++ with a monolithic executable. Grew to millions of lines and thousands of classes in a single library, with build times measured in hours. It scaled the traffic and stopped scaling the team.
V3 (2002–2007): Java, rearchitected into domain-partitioned applications. Split by function, with a database per functional area, and horizontal partitioning within.
V4 (2007 onwards): services, polyglot persistence, event-driven integration.
The pattern
Each generation was a response to a different limit:
| Generation | Limit hit |
|---|---|
| V1 → V2 | Raw throughput of the runtime |
| V2 → V3 | Team scalability — build times, coupling, coordination |
| V3 → V4 | Independent deployability and heterogeneous data needs |
That progression is the useful part. The limits arrive in a predictable order, and the second one — team rather than traffic — is the one organisations consistently fail to anticipate. A codebase can be fast and still be unworkable.
The principles eBay's architects drew from it
Their widely-cited "scalability best practices" writing crystallised several rules that have aged well:
- Partition everything. Split by function first, then horizontally within a function.
- Asynchrony everywhere. Prefer event-driven integration; it decouples availability and lets components fail independently.
- Automate everything, including adaptive systems that tune themselves rather than requiring operator configuration.
- Remember that everything fails. Design for it explicitly.
- Embrace inconsistency. Choose eventual consistency where the business tolerates it; do not pay for distributed transactions by default.
The lesson about rewrites
eBay's rewrites succeeded, which is unusual and worth examining. The distinguishing factors: each had a specific named limit rather than general dissatisfaction; the business kept running throughout; and later generations were incremental — V3 to V4 was a progressive decomposition, not a big bang.
The rewrites that fail are the ones motivated by "the code is bad" with no measurable constraint and no incremental path.