eBaymag magic: under the hood of the international eBay spinoff

Starting way back in 2014—and right up until early 2022—Evil Martians has been the core technical team working on the eBaymag product, with our operations covering all the major technical areas: product analytics, UI design, the tech stack itself, the infrastructure and its maintenance, and feature releases. We built the current version of eBaymag from the very first line of code, and as the project has undergone many transformations over the course of its progression, a side-effect of these changes is that Evil Martians itself has undergone a bit of a metamorphosis, too.

Open borders for successful sales

eBay is an ecommerce pioneer and a global marketplace leader that offers sellers the ability to grow a business with low barriers to entry, regardless of the seller’s size, background, or geographic location. As they like to say: ”We win when our sellers succeed“.

Yet, in spite of these ideals, seven years ago, eBay was essentially composed of purely domestic classifieds. This means that American sellers sold mostly to their fellow Americans, and likewise, Britons targeted customers who were physically located in the United Kingdom.

This happened because eBay initially matured as an American company, and only after a couple of years, it kickstarted international offices. To allow for rapid growth, each regional site developed in an isolated market for a long time. And although there was a certain level of unification and a single branding, these regional sites had no unified catalogs, currencies, amongst other discrepancies.

And indeed, right along these same lines, the eBaymag project began as a small website featuring some guideline documentation for sellers alongside a call center to support them, and it was targeted to just one domestic market. As fate would have it, eBay quickly realized that local sellers were primarily using their site for cross-border commerce. Accordingly, upon grasping the implications of this situation, the platform was tweaked to let sellers easily target foreign customers, resulting in a 50 percent surge in exports.

Flash forward to today: eBaymag is now an official eBay’s B2B tool helping sellers implement cross-border trades to sell their listings on markets as diverse as France, the United States, Canada, Australia, Great Britain, Spain, as well as many others. In fact, in total, 120 territories and 9 local sites are available for cross-border transactions.

As a result, the platform sees up to 55% more sales, and makes it so that sellers need not solely depend on their local markets. Moreover, the tool has seen widespread adoption, and over 51 thousand accounts regularly use it to publish products for sale.

With just a few clicks, sellers can export their goods from one international eBay site to another (for instance, from eBay.com to eBay.fr, or to eBay.de). Prices are automatically set based on the local currencies, and the process is typically quick, taking just about 20 minutes. Further, sellers are able to work with an interface configured to their native language, but the names and descriptions of the items are automatically translated to any local language spoken in the country where the sale will be exported. Beyond the simple fact of convenience, this feature also makes it possible for sellers from emerging countries to offer their products to buyers from more mature economies.

And we’re proud to say that the Evil Martians team implemented all the features listed above!

7 years of changing the tech stack

The story began in 2014: the eBay marketing team had become interested in our previous ecommerce experience and wanted Evil Martians to cover all the tech-related particulars, developing promising features with hopes of achieving a surge in business results.

eBaymag was an internal startup initiated by eBay’s Emerging Markets team. Their goal was to test marketing hypotheses in order to quickly develop features tailored for sellers. In addition, in an environment where each regional site had its own standards, Evil Martians had the task of providing a site-agnostic user experience in the infrastructure in a case where this was not originally planned or embedded in the app’s architecture and APIs. Therefore, it was faster to implement the project on top of already existing solutions. Further, the platform didn’t take advantage of its engineering team in the countries eBaymag supported. That’s why we were tasked with the entirety of product design while the eBay team themselves remained responsible for strategy and logic.

eBaymag was a huge, complex project that experienced 3 pivots, several infrastructure migrations, a change of software architecture and UI design, and reams of updates. During our involvement with eBaymag, the number of Martians working on the project would vary. All in all, at different times, around 20 Martians rotated into the team.

As time has rolled on, the platform’s technological stack has changed (although, it has always remained a Ruby on Rails application at its core). For instance, the stack has included PostgreSQL, Redis, Elasticsearch, GraphQL, React.js, Redux, and Webpack.

We dealt with such a number of challenges and experienced so many epiphanies over the course of the project’s 7-year runtime that it would simply not be possible to list them all in an economical way. Instead, let’s talk about some of the most inspiring of the bunch.

Integration with delivery services

On the tech side of things, one of the most interesting eBaymag developments was centered around logistics. The Martians integrated eBaymag with popular local postal services to assign order delivery within a single interface. As a result, this simplified logistics procedures for local exporters.

These integrations required traversing a bit off the beaten track, as we had to merge eBay’s public API and deliverer APIs all amidst a never-ending stream made up of thousands of orders. Adding another complexity, we also had to deal with extremely sensitive data—personal data with addresses and payment details—and we needed to protect them.

eBaymag helps sellers automatically calculate the cost of a shipment, compile the necessary documents, and to make payments online. In addition, buyers may now also track their orders via a personal account on eBay by using an automatically assigned tracking number.

As a result of our implementations, sellers can process documents and pay for international shipping in minutes instead of hours. The time to process a package was shortened from an average rate of 1.5 hours down to an incredible 3 minutes. Moreover, delivery profiles are customizable—sellers can adjust prices, apply rate charts and shipping restrictions (by size or weight).

Automatic translation

Another one of the crucial features under our purview was the automatic translation of product names and descriptions into the local languages of the largest eBay sites: English, German, French, Spanish, and Italian. The translation was facilitated via Google Translate. To optimize this process, we built a special open source library—google_translate_diff, a Ruby gem. It caches previously translated lines in order to avoid the need to perform duplicate translations. Also, the gem parses incoming data to determine items that are not required to be translated (like HTML code, for instance).

In the end, as a result of our efforts, automatic translation costs were reduced by 3 times.

GraphQL in action

While working on enhancing the tech stack, Martian backend and frontend engineers migrated the product to GraphQL in the process. This was our first complete GraphQL migration, and in turn, it kickstarted the popularization of GraphQL which would spin up internally within Evil Martians. In this field, we help publicize this technology by creating detailed tutorials, articles, speeches, and online and offline seminars.

Evil Martians gradually introduced GraphQL because we didn’t want to somehow fracture or completely rewrite the service’s interaction logic. This was a real puzzler; we had to get Redux and GraphQL to work together. To interact with the GraphQL backend, we used Apollo—and in the process, we learned how to do it properly.

Dealing with eBay APIs

For the first few years, our primary goal was to rapidly evolve the platform by reworking, enhancing, and polishing all the tools and technologies we utilized. For each eBaymag deployment, we used the public eBay API, which didn’t require participation from the primary eBay engineering team—although we did nevertheless communicate and ask questions as needed. The API architecture assumed certain conditions:

• All the features were implemented as API integrations under many restrictions: the number of eBay API calls per certain period, and the estimated completion time.
• There were almost no synchronous operations.
• We had to deal with thousands and thousands of data streams. Each item had a massive amount of contiguous data to exchange between sites—descriptions, product images, limits, permits to be sold in particular countries, and so on. When combined with the already significant amount of time needed to process the request via API, each process could take ages, especially for sellers with thousands of items. Everything was a slow undertaking since we had tens of API requests for each product, while a seller could have over 1,000 products at a time.
• Ever and again, eBay sent us an avalanche of events to process. To tackle the huge event’s volume, we built a proxy service that stored events in a database and allowed processing them in small batches.
• The eBay team had just begun to develop their API documentation, and Evil Martians created some docs on their own.
• There were a lot of architectural alterations on the project.

We had to take into account these restrictions and simultaneously implement significant changes, complex features, and integrations. How did we cope with the situation?

1. We differentiated our teams to dive deeper into their tasks.
2. A dedicated QA team was created to work on the eBaymag platform.
3. We reused components as much as possible and did everything we could to keep things under a reasonable budget.
4. We implemented the “event processing” approach to coordinate thousands of asynchronous tasks.

Moreover, eBay has two sets of APIs: “classic” XML APIs, and newer REST APIs that require different authentication and, critically, which support different workflows: you need to use both simultaneously. Our team wrote (and published as open source) three different Ruby libraries to deal with both APIs at the same time:

• omniauth-ebay-oauth allows devs to implement a super-easy login with a “Sign in via eBay” button correctly handles newer OAuth token retrieval for authenticating calls to both generations of eBay APIs: legacy classic XML-based, and new REST-based APIs.
• ebay_request simplifies working with eBay XML APIs.
• ebay_api for working with REST APIs.

Nailing the frontend

Figuring out the project’s frontend was a bit of a brain-teaser. The application itself has been operational for more than 7 years and it’s now composed of a huge number of components as well as tricky business logic. The task of maintaining a project in motion was a real challenge. Thankfully, we solved it by taking the following actions:

• We kept our stack regularly up to date by updating React and other libraries to their latest versions.

• We did everything possible to control complexity. For instance, we always oversaw code quality and arranged for regular refactoring in order to get rid of errors and kludges. We also built several plugins for Webpack to automatically clean out unnecessary code from the codebase.

• We conquered any fears of large data volumes and learned to display and update thousands of products on the client-side without any performance issues.

• We didn’t have a full-scaled SSR (server-side rendered application), but we managed to make eBaymag’s homepage SEO-friendly using React. In fact, long before it was trendy, we had already adopted React and had many ready-to-go components in the bank.

• We created our own style guide, which had a separate assembly. The guide is now under regular designer review.

Boosting sales with analytics and Growth Hacking

eBaymag is a project where in-depth analytics and a culture of rapid change and hypothesis testing are fundamental to business arrangements, the entire development approach, the selection of the most profitable features, and the distribution of engineering resources. These methods have been used in product management and design, turning the entire eBaymag project into a continuous experiment from cohort analysis to usability testing.

First, Martian account managers are responsible for all product analytics: they shape metrics and monitor funnels and cohorts to see if new features have affected business metrics.

Second, we started to utilize Lean Software Development methodology—this brought with it a culture of rapid change and hypothesis testing. It’s worth mentioning the special role of our designer: we put this person in charge to ease product growing pains when the project started to mature and scale.

This approach helped us to involve and motivate all the stakeholders from engineering, design, support, marketing, and business, orient them toward business goals, and to define priorities as the scope of the project continued to grow. In terms of what we should be developing, we reshaped the entire production process from reactive to “proactive”. We also applied more analytical tools and data sources to measure success at each step and to gather feedback in order to confirm the success of a feature or to try and take a lesson from something which had ultimately failed to deliver results.

Third, since late 2019, Evil Martians have made use of Growth Hacking while working with eBaymag. We consider Growth Hacking to be good practice for task prioritization, and we believe it works in parallel with the usual development processes. At the same time, it saves resources and brings about tangible business results. This methodology helped the team to focus on growth tasks and to precisely select the features that would bring more value while also finding resources for contributing to the overall product development and to maintaining product operability.

In terms of gains, eBaymag’s revenue has increased more than 3 times from the moment we started to tap into Growth Hacking, and our brief eight-month experience has already brought eBaymag up to +214% of its key metric growth.

Creating the best product design for sellers

The collaboration with eBay helped Evil Martians increase and level-up our UI design team.

eBay’s headquarters released new design guidelines for its core service, and the Martians faced the task of completely changing the design. eBaymag is an official eBay product, so its alignment with the eBay’s core product design is a key factor to be considered.

We developed a new design system including corporate colors, typography, buttons, grids, and other elements based on the eBay palette, but with a component system suitable specifically for this project.

It should be noted that product design was based on analytics and Growth Hacking foundations since our designers carried out usability tests, tracked user reactions, obtained feedback and requirements, and tested hypotheses created on this basis.

Evolving DevOps

We also were responsible for the entire infrastructure itself. 7 years ago project started as a proof of concept, and to get it to market faster we used Digital Ocean droplets (without any droplets orchestration). Since we had recently mastered the Chef configuration management tool, we opted for it first. Additionally, our first deployment process relied on Capistrano.

Through the years, the project experienced rapid growth and required more scalability. In 2015, we decided to try a bleeding-edge orchestration solution: Kubernetes!

There were no manageable Kubernetes cloud platforms back then, so we wrote a Chef cookbook to deploy Kubernetes manager-plane and uniformed worker nodes. Also, in 2015, we rolled out new infrastructure on Digital Ocean, thus becoming one of the pioneering teams to use it in production (literally—nobody had heard of Kubernetes at that time).

There were almost no public Helm charts for any software we needed, so we again wrote our first versions of Helm charts for Prometheus, the ELK stack (which was not adapted to run on Kubernetes entirely), as well as some others.

The project also pioneered other cutting-edge technologies. eBaymag was the first project that Evil Martians moved to Google Cloud Platform—and this was almost immediately after Google Kubernetes Engine had been announced and made usable. This was the point of no return: we got our hands on full-scale auto scaling, as GKE was closely integrated with GCP from scratch.

The eBay team gave us free rein to experiment with various technologies and settings, like switching back and forth between different test builds of the Ruby interpreter (we experimented with CRuby and Fullstaq Ruby. The experimentation allowed us to reduce Ruby’s RAM usage by 2-3 times and set up auto-scaling of our Sidekiq workers in order to process enormous amounts of eBay notifications at peak times (and both solutions reduced infrastructure costs dramatically).

Today, the project relies on Terragrunt to manage GCP objects and on Argo CD setup to manage the objects inside Kubernetes clusters. Our default Argo CD setup brings us all of the essentials a project like this might need: a carefully polished Prometheus monitoring setup (and it’s also prepared to handle the application monitoring), logs aggregation, a couple of Ingress controllers, and some other useful operators.

Martian open source projects

For the eBaymag platform, we used 24 Martian open source projects, and two-thirds of these were utilized to improve performance optimization and engineering processes. The project also gave us the chance to bring some of our leading products and projects to the table—AnyCable, imgproxy, and Lefthook. Let’s give a quick rundown of a couple more you might not have heard of!

Blood Contracts

As we had to deal with API architecture, we needed a tool for fast and reliable integration development with different APIs and for further scaling from there. We designed a Ruby gem for runtime data validation and monitoring using the contracts approach. With it, you can release a raw version of API integration and ensure that nothing will break in production. This allowed our releases to launch much earlier. To illustrate, before Blood Contracts, it took about a year to integrate with DHL, half a year for the next delivery service—but in the case of UPS, we were able to integrate in just a couple of months after switching to Blood Contracts.

Yabeda

To make setting up monitoring for the whole application easier, we added custom code to export Ruby application metrics to Prometheus. This was especially useful for Sidekiq, the background task queue processing tool eBaymag relies on heavily. This was later used in the Yabeda instrumentation framework.

TestProf

To speed up the testing of large integrations and reduce deployment time (and to make test design easier), we used TestProf—a performance analyzer for Ruby tests with the power to cut test runtime by half.

Fixturama

This collection of helpers for dealing with fixtures first appeared in another Martian project with eBay—eBay Bonus, and half of the tests on eBaymag were built with its help. It allows us to write graceful tests that require a lot of data without cluttering them with details.

And a couple of words about some other gems. We introduced feature_toggles to easily group users for Growth Hacking, after_commit_everywhere to avoid errors with isolation violations of transactions. Finally, Clowne is a powerful and customizable Ruby gem for cloning models, and a savior due to its “create similar” feature for complex data models.

Time to say goodbye

As typically happens in our long-term projects, we’ve approached the stage of the project where it’s stable and developing nicely, so it’s time to do what we usually do at the point where Martian expertise and speed are no longer needed—help hire or assemble a team, pass on our knowledge and ensure that the project is running in good hands in a cost-effective manner (albeit, in the case of eBaymag, we do this with a hint of nostalgia).

All in all, eBay was a landmark project in terms of cooperation. It represented a rare example of a market giant somehow retaining the spirit of a startup, and this atmosphere allowed Evil Martians to create, design internal products and hypotheses, invent and implement new smart features, and build up a sound engineering culture. Truly, Evil Martians became a part of the eBay team.

So, all’s well that ends well! By the way, it doesn’t matter if you have a large business or a startup still running in the initial stages—if you want to benefit from our experience with a project like eBay did, including microservices, API integration, or full-cycle product design—drop us a message!