This is @deeeeet from Cross Border (XB) Engineering.

As we shared at our recent business strategy presentation, we have released a new global version of the Mercari app to further accelerate Mercari’s global expansion.

This app is a new application, different from the currently available Japanese and US versions of Mercari, and we have also rebuilt the backend infrastructure from scratch. In this article, I’ll introduce the strategy and architecture of the global app and its infrastructure from an engineering perspective, while reflecting on the lessons learned from Mercari’s past challenges.

Cross-Border Transactions at Mercari

Some of you who have listed items on Mercari Japan may have experienced your products being "proxy purchased" by businesses rather than general customers. This is made possible through a cross-border (XB) transaction system that allows overseas customers to purchase items listed on Japan’s "Mercari."

Cross-border transactions at Mercari are realized through partnerships with proxy purchase partners. Overseas customers first order Mercari products on partner websites. The partner then purchases the items on Mercari as a proxy buyer and handles the payment process. Domestic sellers ship products to the partner’s designated warehouse in Japan, just like regular domestic transactions. After the products arrive at the warehouse, the partner inspects and repackages them for international shipping, then sends them to overseas customers.

This system benefits both overseas and domestic customers. Overseas customers can easily purchase unique Japanese products without worrying about language barriers or currency differences. Meanwhile, domestic customers can expand their sales opportunities globally without any need for direct communication with overseas customers or complex international shipping procedures – they can sell just like in domestic transactions.

This cross-border transaction business started in 2019 and has grown significantly in recent years, with GMV growing 15x over the past three years. Anime, comics, games, and entertainment-related goods categories account for much of the total transactions, showing strong demand from overseas customers.

Given this strong demand and growth, in addition to the proxy purchase partner site system, we also started an initiative to enable proxy purchases through Japan’s Mercari web service. This system allows overseas customers to create accounts directly on Mercari and search for and purchase products through the Mercari experience (while still maintaining the partner company intermediary transaction). We released this initiative in 2024, and it’s currently available in Taiwan and Hong Kong, with growing user numbers.

While this cross-border transaction business has grown steadily, several important challenges have emerged. As explained below, the existing JP system was built specifically for the Japanese market and designed with single-currency and single-language assumptions. Since cross-border transaction features were added on top of this, there were limitations to expanding to multiple countries and adapting to each country’s unique business practices. There was also a competitiveness issue with only web version availability, especially in Asian markets, where most EC usage is mobile-based.

Despite these challenges, demand from overseas markets clearly exists, with particularly high interest in anime and game-related products. While currently limited to Taiwan and Hong Kong, similar potential demand clearly exists in the US and EU markets. To maximize this opportunity, we needed a new approach to expand to more countries faster.

Therefore, we decided not to simply extend the existing system, but to build a new application and infrastructure designed for global expansion from the ground up. This was a strategic decision looking ahead from cross-border transactions to eventually launching local marketplaces in various countries and ultimately realizing a global marketplace that transcends borders.

Approach to Global Expansion

Realizing a global marketplace has been Mercari’s vision since its founding, and this is not our first challenge in global expansion. We have challenged ourselves with business expansion in the US and continue to focus on its growth. We also have experience attempting expansion into the UK in the past.

In previous global expansions, we took the approach of building local C2C marketplaces from scratch in each country, similar to Japan. However, the latest global expansion takes a new approach, learned from the successes and challenges of cross-border transactions. We’re adopting a strategy that focuses on "cross-border transactions," delivering products from Japan to overseas as the business axis, then gradually expanding services while leveraging the customer base built there. The expansion pace is also significantly different from before, aiming for 50 countries within 3 years. This represents a shift in strategy to start by delivering the unique and abundant products listed by Japanese customers and businesses to the world, then exploring further possibilities from there.

This shift in business strategy has also significantly changed our engineering strategy.

Previous expansions in Japan, the US, and the UK were each realized through independent, different systems. Of course, initially, we took an approach of deploying a common codebase to each country (though with separate data). However, due to code complexity from adapting a system built for Japan to each country’s circumstances (e.g., “if” statements for country switches written in many places) and decreased decision-making speed in each country due to the need for alignment between countries, we ultimately decided to fork, resulting in independent systems with separated development and operation structures for each. The US subsequently redesigned its app to match local UI/UX and implemented unique features on top of it, so Japan and the US systems remain separated today.

This method was effective for quickly launching businesses and deeply optimizing for each country’s market. Creating independent organizations and developing systems for each country’s business growth was also important. However, from a longer-term perspective, the following challenges made it difficult to connect to the next expansion:

• Cost and speed of expansion: From the perspective of increasing the number of countries, common infrastructure wasn’t prepared, and when considering the next country, we would need to rebuild new applications and backend infrastructure.
• Inefficiency of development resources: Similar features were implemented individually in each country, requiring dedicated teams for each infrastructure, causing duplication and inefficiency of development resources.

"Cross-border transactions" themselves are alreayd built on the existing JP system. However, as described in more detail below, the existing system has become complex, and there were limits to expanding countries faster and providing better UI/UX for global markets. And connecting to what comes after "cross-border transactions," such as launching local marketplaces in new countries, is extremely difficult.

To fundamentally solve these challenges and efficiently accelerate new international expansion centered on "cross-border transactions," we needed a new strategy. So we established a new vision of "supporting all countries and regions with a single global infrastructure rather than building individual systems for each country or region" and began developing that infrastructure.

Global Foundation Development Strategy

Several approaches were considered for developing this single global infrastructure, and we chose a "hybrid approach of extension and reconstruction." Let me explain the background leading to this approach through the evolution of Mercari’s backend systems.

Evolution of Mercari’s Backend Systems

Mercari’s backend system started as a Monolith architecture (implementing all features in a single codebase). This is why we could choose the fork option when starting US and UK businesses (though duplicating the many mechanisms and tools supporting each country’s scale in the infrastructure behind the scenes wouldn’t have been easy).

Around 2017, the scale of the Japan organization began to expand rapidly. Organizational growth made it difficult for many people to develop simultaneously in a single massive codebase, and bugs in some features often caused failures that affected the entire service. Additionally, most systems were built on-premises, and their operation and expansion became bottlenecks. To solve these problems, we began migrating to Microservices architecture and the cloud (along with transitioning to DevOps). I joined just before this, and have been responsible for promoting the migration project and establishing and expanding the Platform Engineering team that prepares the foundation and tools for Microservices development.

We adopted the Strangler pattern as our approach to Microservices architecture migration. This involves placing a Gateway in front of the existing system and gradually migrating traffic to the new system around that Gateway. More specifically, we repeatedly (1) extract feature groups implemented in the existing system as Microservices and (2) route usage traffic for those features from the Gateway to the Microservices side, gradually migrating to the new system. Several years have passed since migration began, and we’ve extracted many features from the Monolith and developed new features on top of them. Cloud migration for almost all services is also complete (over 100 services).

After Microservices migration, Japan began launching multiple new businesses in addition to the main C2C marketplace business. These include Merpay for fintech, Mercoin for cryptocurrency, Mercari Shops for B2C business, and Mercari Hallo for on-demand work. Merpay extracted Mercari’s payment system and built it as Microservices architecture on the same infrastructure platform as C2C. Mercoin has largely separated infrastructure for security but basically develops with similar architecture patterns. Shops has Microservices architecture but is an independent system separated from C2C (while it’s one mobile app, the backend is separated).

Alongside these years of Microservices migration and multiple business launches, we have also promoted the development of common infrastructure. Not only development infrastructure and tools at the Platform engineering layer that I’ve led, but also foundation that can be used across multiple businesses like ID platform, payment platform, and marketing platform.

This is the evolution of Mercari’s backend systems since its founding.

Challenges with Existing Systems

Looking at the existing systems holistically in 2025, there are several challenges, but the biggest is that core functions important for the C2C marketplace remain in the Monolith infrastructure. While we’ve been able to extract some features as Microservices using the Strangler pattern, this approach only extracted upper-layer features as proxies and didn’t progress to data migration in many areas (meaning dependencies for data retrieval remained). In particular, we haven’t been able to extract very important C2C functions like "transaction management" and "shipping" from the Monolith and its DB. A major reason is that these two have strong logical coupling that couldn’t be separated easily. Therefore, strong dependencies on the Monolith still remain. While this area still requires much development and changes, it remains on a complex codebase, requiring urgent action. As someone involved in Microservices migration from the beginning, not tackling these important parts early is a major regret.

Looking at global expansion, this becomes a major challenge. Transaction management and shipping systems remaining in the Monolith are designed specifically for the Japanese market. Transaction management assumes only Japanese yen, and adding support for multi-currency transactions, exchange processing, and different tax systems in each country would be very costly. The shipping system is also tightly coupled with Japanese domestic carrier systems, making it difficult to support local carriers in each country and different shipping options without fundamental rebuilding.

There’s also the system divergence problem between C2C marketplace and B2C Shops. Currently they have separate transaction and shipping systems, and product management is also separated, resulting in inability to provide a unified experience even to the Japanese customers. This is due to independent services being considered in the original vision, and even when the direction changed to integrate them, execution was difficult due to the Monolith problem above.

There are also challenges with Microservices architecture itself. As a result of emphasizing ownership and freedom for each service and not achieving sufficient abstraction between services, and by not properly separating domains and making division units very small, many small Microservices with slightly different implementations were built. This has made Microservices operation costs very high. Mercari frequently reorganizes to move forward with speed, but each time requires transferring Microservices ownership, and implementation differences increase onboarding costs.

Due to these constraints, it became clear that proceeding with global expansion as an extension of the existing system had both technical and business limitations.

Direction for Global Foundation

Based on this evolution and current challenges, we considered several approaches for developing the global foundation. First, taking the fork option, like past US expansion, has become very difficult. Duplicating many microservice systems is not realistic. We also considered rebuilding everything from scratch, but excluded this option from a cost and efficiency perspective. In conclusion, we chose a "hybrid approach of extension and reconstruction of existing systems."

In this approach, determining where to draw the line between extension and reconstruction was important. Many existing systems are specialized for the Japanese market, and many services have been converted to Microservices. Extending all of them wasn’t realistic, and since the Japan business continues to be important, it was also important that global expansion could proceed independently from it. We also had a strong desire to avoid global dependencies on the remaining Monolith.

For "extension," we mainly decided to utilize the common infrastructure developed alongside multiple business launches. We specifically selected services that require strong expertise and are designed with extensibility in mind. As described in detail below, we’re also considering moving away from Microservices, deciding to depend not on small, detailed services but on sufficiently large and independent "domains" (at a level that could be replaced by SaaS). Based on these criteria, for example, we’re making the ID infrastructure globally common, and connecting the payment infrastructure to Stripe through the Merpay infrastructure to support global currencies and local payment methods. We’re also utilizing existing systems by extending search infrastructure, marketing infrastructure, and others.

Other parts take the "reconstruction" option. In particular, the aforementioned C2C service "transaction management," "shipping," and "item/product management" had to be rebuilt. To avoid the same problems as Japan, we’re building with consideration for (1) making each loosely coupled for easier long-term extensibility, (2) treating C and B products equally to provide unified UI/UX, and to enable multi-country expansion and new local marketplaces in other countries, (3) flexibly supporting each country’s currency, language, tax/customs systems, and regulations (assuming “Design for Two” – see Tenets below), (4) being able to handle products and shipping methods from countries other than Japan.

Also, simply rebuilding would just create a new, separate infrastructure. While initially focusing on global success, we’re moving with the assumption of eventually replacing Japan’s C2C and B2C infrastructure as well (having actually achieved release, we’ve started a project to utilize this infrastructure in Japan too).

For mobile apps and Web, a different UI/UX is essential globally, so we chose to rebuild. Additionally, by renovating the backend, we can switch the API itself and improve implementation.

From Microservices to Modular Monolith

To tackle the challenges of Microservices architecture described above, we’re developing the "reconstructed" backend infrastructure as Modular monolith architecture.

Challenges of Microservices

The main reason Microservices architecture operation costs became high at Mercari is that we gave too much development freedom to each service. We’ve promoted minimal technology stack unification: Go for server implementation, Spanner/CloudSQL (MySQL) for databases, and Kubernetes for infrastructure. On the other hand, the repository strategy was Polyrepo (1 service = 1 GitHub repository), and while there were baseline templates and minimal common libraries, repository structure and implementation policies were left to each team. Therefore, while they’re all Go Microservices at a macro level, quite different services were mass-produced at a micro level. Even if each service’s operation cost is small, when you need to manage multiple different services, the differences prevent standardization, increasing costs.

Additionally, Mercari moves forward with speed and frequently changes direction, so organizational changes are frequent. This requires frequent Microservices ownership transfers. Each transfer requires onboarding, and implementation differences increase that cost. It also makes promoting standardization difficult.

Also, especially on the C2C side that migrated from Monolith, there are many areas where proper domain separation wasn’t achieved, with low service cohesion in many places. This requires changes across multiple services and teams for feature additions, leading to increased communication costs. Strengthening ownership for each service conversely, made it harder to accept changes from outside.

The approach that successfully addressed these challenges with Microservices architecture implementation was Mercari Shops’ Monorepo approach. This method puts all Shops-related Microservices in one repo, achieving abstraction and unification of implementation between services, reducing operation costs from multiple services. It provides a Monolith-like development experience while services are separated and deployed behind the scenes (gaining fault tolerance benefits), incorporating the best of both worlds.

However, even this approach has challenges. Managing and maintaining infrastructure and automation mechanisms for this Monorepo is very costly (being built largely separate from existing Platform prevented collaboration with the common infrastructure teams). Testing, deployment, and development environment construction for Microservices inevitably becomes complex. For example, the test environment takes a wealthy approach of duplicating all services for each PR. They also strictly separate DBs for each service, increasing infrastructure costs.

Modular Monolith

Given this background, we chose Modular monolith architecture for building the new infrastructure. It’s not just Modular monolith but designed to deploy specific Modules independently when necessary (close to the Service Weaver concept).

I believe the initial Mercari Monolith was unable to properly separate domains and modules, causing code tight coupling and resulting complexity. We’re avoiding similar problems by clearly organizing service boundaries and dependencies for each module. We’re avoiding complexity from over-separation like Microservices, creating modules with sufficiently condensed functionality. At the same time, we’re also enabling Microservices-like fault tolerance benefits by allowing independent deployment when necessary.

In the initial development phase with not many people, we basically don’t limit ownership to specific modules (though of course some people are stronger in specific areas). We want everyone to have ownership of the entire codebase. This allows module assignments to be dynamically determined by product development priorities, eliminating the wasteful communication coordination costs that occurred with Microservices. Meanwhile, even as the organization expands in the future, assignment by module unit is possible, and there’s room to solve the problems we encountered with the previous Monolith.

Being a Monolith makes local development environment construction easy with one binary, and testing and deployment become simple, eliminating development burden caused by Microservices and creating a better development experience. Infrastructure and CI/CD infrastructure can directly use what the Platform Engineering team provides, avoiding the infrastructure operation costs that the Shops Monorepo approach fell into.

However, this policy is new within the overall organization, and there’s the challenge of how to coexist with the existing Microservices approach. Realistically, it’s not easy to return all separated Microservices to a Monolith. Therefore, Microservices themselves will likely remain in the future. To reduce Microservices development and operation costs, it’s important to adjust service division units to more appropriate levels, and furthermore, increase unification through Monorepo approaches like Shops achieved. And for future new businesses, unless there are special reasons, I think we shouldn’t choose Microservices architecture as the first move. We’re also considering horizontally expanding this global infrastructure’s Modular monolith construction pattern and standardizing implementation patterns.

Technology Stack

Below is a list of technology stacks used in building this infrastructure. Basically, we’re not making major changes from the stack Mercari has cultivated, but utilizing them well.

• Infrastructure: We continue to use Google Cloud as our main cloud. The main region is Tokyo, but we’re considering using other regions in the future (especially from a performance perspective). For application execution infrastructure, we use Kubernetes (GKE) managed by the Platform Engineering team.
• Database: We chose AlloyDB for the database. While we’ve mainly selected Spanner centered on Merpay, we chose AlloyDB considering (1) avoiding lock-in as much as possible, considering we might not be able to handle everything with Google Cloud when considering long-term expansion, and (2) using the better development experience ecosystem with PostgreSQL. We’re also considering CockroachDB and may consider switching depending on future expansion.
• Languages/Frameworks: Go for servers, Swift for iOS, Kotlin for Android, and Next.js (TypeScript) for Web. We haven’t changed much here.
• Monorepo: More detailed blogs will be written later, but iOS, Android, and Web are each developed by extending JP service repositories as Monorepos. By extracting modules that can be shared between JP and global and unifying CI/CD, we’re improving development and operation efficiency.

Tenets

This backend infrastructure development includes many members from our India base as well as Japan. For members from various backgrounds to realize the direction introduced above, it’s important that everyone can make decisions following the same guidelines. To achieve this, we established "Global Engineering Tenets." Tenets are inspired by Amazon’s Tenets: supercharging decision-making.

Let me introduce some main Tenets:

• Design for two: In software development, you probably intuitively understand that it’s easier to increase support for a feature from 2 to 3 than from 1 to 2. For example, if an application already supports two languages, adding a third language is easy. On the other hand, if an application only supports one language, adding a second language requires much preparation like i18n mechanisms. The same applies to global expansion. Adding new regions or countries to infrastructure already supporting multiple countries/regions is much easier than extending an application for a single region/country. We always assume 2 or more countries in feature and system design.

• Global by default but enable localization: While advancing system development for global use, we don’t just expand business to multiple countries but implement localization measures in major markets. Therefore, systems need to be quickly and easily expandable to multiple countries while also having flexibility to support specific country requirements. In the long term, we may establish local engineering teams for localization, and they need to be able to independently develop localized features.

• Learn and unlearn from past experience: We have many parts that are newly "reconstructed" this time. However, this shouldn’t be completely new but should utilize past learnings introduced above as important assets. I’ve explained the overview, but there are challenges to review in various areas like mobile development, web development, product development, etc. We strongly asked newly hired members to utilize these as well.

• Keep each country’s business isolated: Even when utilizing existing infrastructure and platforms, they shouldn’t affect each other. For example, we need to avoid bugs or incidents occurring globally affecting JP business, or vice versa.

Future Work

With this release, we’ve completed implementing basic functionality. Going forward, we aim to implement features important for cross-border transactions, such as B product pre-order functionality and authentication features, while rapidly increasing the number of countries we expand to. We need not only horizontal expansion but also localization and growth in specific countries, entering a phase of further utilizing the infrastructure. Also, as introduced above, the infrastructure itself is designed to be usable in JP, and we’ve started that replacement project.