7 Proven Scalability Practices from eBay’s Architecture

At eBay, scalability is a daily architectural pressure, with billions of page views and petabytes of data requiring a design where resource consumption grows linearly (or better) with load.

Best Practice #1: Partition by Function

Group related functionality together and separate unrelated parts, reducing coupling and allowing independent scaling of each function.

At the code level, JARs, packages, and bundles isolate features. At the application level, eBay runs sales, bidding, and search in separate server pools—about 16,000 servers split into 220 pools—enabling targeted scaling and resource isolation.

Similarly, databases are partitioned: user, product, and purchase data reside on distinct logical databases across 400 physical hosts, allowing independent scaling of each data type.

Best Practice #2: Horizontal Sharding

Beyond functional partitioning, workloads must be broken into smaller, manageable units. Stateless application servers are load‑balanced, and adding capacity is as simple as provisioning more servers.

For stateful data, eBay shards databases by primary access paths—e.g., user data across 20 hosts, with each host storing 1/20 of users. Sharding strategies include simple modulo, range partitioning, lookup tables, or hybrid approaches, all designed to support easy re‑sharding as data grows.

Best Practice #3: Avoid Distributed Transactions

Instead of costly two‑phase commits, eBay relaxes cross‑system transaction guarantees, favoring availability and partition tolerance per the CAP theorem.

Most operations are auto‑committed; only carefully defined cases bundle statements into a single transaction. Eventual consistency is achieved through ordered DB operations, asynchronous recovery, reconciliation, or batch settlement, chosen based on use‑case consistency needs.

Best Practice #4: Decouple with Asynchronous Strategies

Asynchronous communication (queues, multicast, batch jobs) removes tight coupling, allowing components to scale and remain available independently.

Infrastructure should adopt asynchronous designs at all levels, using patterns like SEDA to keep programming models simple while avoiding synchronous dependencies.

Best Practice #5: Turn Processes into Asynchronous Streams

Convert latency‑tolerant work (tracking, invoicing, reporting) into background streams, reducing user‑perceived latency and smoothing load spikes.

Asynchronous pipelines also lower infrastructure costs by decoupling capacity from peak load, enabling better resource utilization.

Best Practice #6: Virtualize Every Layer

Introduce abstraction layers—virtual machines for OS, ORM for databases, virtual IPs for networking—to make scaling and reallocation transparent to applications.

eBay virtualizes databases, mapping logical databases to physical hosts, and abstracts routing logic for data placement, allowing ops teams to move or merge logical hosts without code changes.

Search also uses a virtualized, partitioned grid that appears as a single logical index to users.

Best Practice #7: Use Caching Wisely

Cache read‑heavy, rarely changing data (metadata, config, static content) using push and pull strategies, while avoiding caching write‑heavy or session data to preserve correctness and availability.

Over‑caching can starve the main system of memory and create a single point of failure; balance cache size against overall system resources.

Conclusion

Scalability is not a non‑functional afterthought; it is a prerequisite for functionality and should be treated as a top‑priority requirement.

Applying these practices can help architects of any scale build systems that grow efficiently and remain reliable.

Source: infoQ – Scalability Architecture Practices