How eBay Builds Resilient Multi‑Data‑Center Applications with MongoDB

Background

eBay operates more than 3,000 non‑relational database instances and uses MongoDB as a core component of its enterprise data platform for customer‑facing services. Continuous availability is required; weekly maintenance windows are no longer acceptable, and commercial server hardware introduces frequent failures.

Design goals

The architecture aims to maximize Mean Time To Failure (MTTF) and minimize Mean Time To Recovery (MTTR). Database choices are evaluated on six dimensions: availability, consistency, durability, recoverability, scalability, and performance.

Elastic MongoDB design patterns

7‑node replica set across three U.S. data centers

Members of a 7‑node replica set are distributed across three data centers (DC1, DC2, DC3). Election priorities are configured so that if the primary in a data center fails, a secondary in the same data center is preferred to become the new primary; only when an entire data center is lost does a secondary from another site become eligible. Writes use a majority write concern ( { w: "majority", j: true }) to guarantee durability across sites.

Read‑intensive / high‑availability pattern

For product‑catalog workloads that require many concurrent reads, the replica set can be expanded to up to 50 members. Additional secondaries increase read throughput (e.g., using { readPreference: "secondaryPreferred" }) while preserving automatic failover and majority write guarantees.

Extreme read/write pattern

Write‑heavy workloads are served by a distributed MongoDB cluster that spans all three data centers, effectively a sharded cluster with replica sets in each zone. This provides high write throughput and resilience to data‑center loss.

Configuration knobs

Developers can tune persistence and consistency per application by adjusting write concern (e.g., { w: 1 }, { w: "majority", j: true }) and read preference (primary, primaryPreferred, secondary, secondaryPreferred, nearest). These settings allow trade‑offs between latency and durability.

MongoDB version features supporting the patterns

MongoDB 3.4 introduced zone sharding, enabling data to be partitioned by geographic zone and allowing durable writes to be directed to specific data‑center zones.

MongoDB 3.6 adds retryable (rewritable) writes, reducing the amount of error‑handling code required in client applications.

References

MongoDB World presentation by Qu Feng (video) and the MongoDB Multi‑Data‑Center Deployment Guide: https://www.mongodb.com/collateral/mongodb-multi-data-center-deployments. Original blog post: https://www.mongodb.com/blog/post/ebay-building-mission-critical-multi-data-center-applications-with-mongodb.