eBay’s Scalability Best Practices: Functional Partitioning, Horizontal Sharding, Asynchronous Decoupling, and More

At eBay, scalability is a core architectural driver because the platform serves billions of page views daily and stores petabytes of data; the system must grow linearly with load rather than merely handle a fixed capacity.

Best Practice #1: Functional Partitioning

Related features are grouped together while unrelated features are isolated, allowing each group to be scaled independently. eBay organizes roughly 16,000 application servers into 220 pools (e.g., sales, bidding, search) and separates databases by domain, resulting in about 1,000 logical databases on 400 physical hosts.

Best Practice #2: Horizontal Sharding

Within each functional area, work is broken into manageable units that can be scaled horizontally. Stateless application servers are load‑balanced, while data is sharded (e.g., user data split across 20 hosts) and re‑sharded as volume grows.

Best Practice #3: Avoid Distributed Transactions

eBay rejects two‑phase commit across services; instead it relaxes ACID guarantees, using techniques such as ordered DB operations, asynchronous event replay, and coordinated batch processing to achieve eventual consistency while preserving availability.

Best Practice #4: Asynchronous Decoupling

Components interact asynchronously via queues, multicast, or batch jobs, allowing each side to scale and remain available independently; frameworks like SEDA provide staged, event‑driven processing without tight synchronous coupling.

Best Practice #5: Shift Work to Asynchronous Pipelines

Moving non‑critical processing (e.g., activity tracking, billing, reporting) to background jobs reduces request latency and lets infrastructure scale to average load rather than peak spikes.

Best Practice #6: Virtualize at All Levels

Virtualization abstracts hardware, OS, language runtimes, ORM layers, load balancers, and routing logic, enabling flexible rebalancing of logical hosts across physical machines without code changes.

Best Practice #7: Proper Caching

Effective caching balances hit rate, memory limits, freshness, and availability; eBay caches slowly changing metadata aggressively while avoiding caching of rapidly changing transactional data, recognizing that over‑reliance on cache can become a single point of failure.

Conclusion

Scalability is a non‑functional requirement that is actually a prerequisite for functionality; the outlined practices help architects design systems that can grow linearly, remain highly available, and adapt to changing workloads.