Evolution of the Architecture of eBay's Android App To Support Scalability
As one of the world’s most popular e-commerce companies, eBay runs over 4000 database servers to support its 18 million sellers and 164 million active users worldwide.
eBay’s Android app, which has been downloaded over a 100 million times since its launch in 2010, is currently on its version 5.10.0.11, and is considered one of the world’s leading shopping apps. It provides simplified access to eBay website’s features, which includes tools for sellers, as well as shop, search and bid options for its buyers. As a result of its huge success, eBay put most of the development efforts into their Android application.
eBay’s Android app, which has been downloaded over a 100 million times since its launch in 2010, is currently on its version 5.10.0.11, and is considered one of the world’s leading shopping apps. It provides simplified access to eBay website’s features, which includes tools for sellers, as well as shop, search and bid options for its buyers. As a result of its huge success, eBay put most of the development efforts into their Android application.

At eBay, one of the primary architectural forces they grapple with every day, is scalability. Every architectural and design decision they make at eBay Inc. is vital towards the scalability factor of their system. With millions of users using their app and petabytes of data in their systems, this is more of a necessity, than a choice. This of course has helped eBay stay ahead of most of its competing apps in the online marketplace.
How Architecture of the App has Evolved to Support Scalability
Microservices Architecture
In a scalable architecture, the usage of resources should increase linearly with load – where load is measured in user traffic, volume of data in the system, number of transactions performed within a given time, etc. In order to support this, eBay’s architecture has evolved from monolithic to microservices over the years. This soon became a key factor in making eBay’s scalability level higher.
Currently, eBay runs more than 1000 services with front-end experiences such as eBay’s Android app, which calls the APIs for those services. There is a back-end service for shipping, a back-end service for bidding – a back-end service for every job. Basically, the app calls intermediate orchestration services that then talk to the back-end services.
Each development team at eBay is responsible for managing its own set of services. When the situation arises where they want to add a new service, they use an internal cloud portal to supply developing/testing, as well as staging and production servers. This type of service orientation removes unnecessary dependencies and makes it easier to divide the work to make new improvements and add new functionality to the system.
Architecture of Databases
When discussing the scalability of eBay’s Android app, the topic of its databases cannot be ignored. eBay’s databases are responsible for caching, metadata configuration and other proper use cases. By the year 2008, eBay was splitting its databases by primary access path, modulo on a key – every database having at least 3 online databases, distributed over 8 data centers. Databases being segmented function-wise; user, item, feedback, transaction etc. – over 70 altogether.
eBay has always been a heavy Oracle user, but over the course of a few years realized that Oracle was not exactly the best fit to support most of its use cases. Quite often, eBay found themselves paying Oracle too much for the services they did not need, while not getting back most of the services that they did need. Simply, having a relational backend, eBay faced numerous challenges as their marketplace grew by the day. It proved to be difficult to scale their system to support the inundation of users and items in their marketplace, since there was a lack of native sharding and replication – all because rigid schemas were hard to manage, and the cost of maintenance was skyrocketing.
As a result, eBay switched a significant portion of its workload to NoSQL databases. For example, eBay now uses Couchbase as a combination of key-value store and document database. Couchbase provides eBay the affordable scalability it needs because of its flexible schema, along with a very high read/write performance and throughput. Couchbase Server’s caching technology allows 300K+ reads/sec on one server, and 25K writes/sec on another. With Couchbase, eBay could easily and dynamically add capacity without any downtime.
Conclusion
It is no doubt that eBay is one of the pioneers of e-commerce, but in 2017 and in the years to come, it faces a very competitive landscape which only seems to increase by the day. This means that eBay has to continually develop its offering to the users in order to thrive in the ever-growing and competitive online shopping marketplace. Since 50% of the revenue eBay collects is from their mobile apps, they are constantly updating their mobile app to provide notably simplified consumer selling as well as buying experience that uses their increasing structured catalogue coupled with a more efficient listing flow.
At eBay Inc., it is their firm belief that it is a mistake to worry too much about scalability from the beginning, but it is also unwise to not worry about scalability at all. You need to develop an application that is capable of dealing with its ever-growing user base as well as with architectural evolution. A system should face necessary changes and adapt according to the evolution of technology and such; otherwise the whole business might lag behind. No system is perfect from the start – when in fact a good system is developed overtime in response to issues and concerns that arises along the way.


Comments
Post a Comment