Mercariのマイクロサービス移行 — モノリスから次世代へ

Mercari has, over roughly the decade since launching its flea-market app, rebuilt its infrastructure from a giant Ruby on Rails monolith into hundreds of small, independent services. This migration was not completed overnight but is a long-term project advanced in phases over multiple years.

Early Mercari handled listings, transactions, payments, and messaging all within a single large Rails application. Initially this enabled rapid development, but as users grew, deploy frequency dropped, the blast radius of failures widened, and onboarding new engineers to grasp the whole system reportedly became increasingly difficult.

Mercari adopted a policy of building new services on Google Cloud's managed Kubernetes (GKE), away from its earlier Sakura Internet–era environment. By running on Kubernetes, container placement, autoscaling, and restart-on-failure could be handled declaratively, aiming for a state where each service team could ship releases without worrying about infrastructure.

For internal service-to-service communication, gRPC was adopted in earnest in place of the original JSON over HTTP. Because client and server code in each language can be auto-generated from schemas defined in Protocol Buffers, gRPC is valued for making it easier to achieve both type safety and backward compatibility.

As the number of services grows, it becomes impractical to implement common concerns — retries, timeouts, mTLS-based authentication, traffic control — inside each service. Mercari has introduced a service mesh centered on Istio, delegating these features to sidecar proxies (Envoy) and thereby abstracting network-control concerns away from application code.

Whereas a single request's flow can usually be followed via stack traces in a monolith, in microservices a single user operation often spans more than ten services. Mercari has reportedly built an observability foundation that integrates distributed tracing, metrics, and logs by leveraging standards such as OpenTelemetry.

Equally important to the technical migration was organizational reform. Mercari has reportedly adopted a model in which "each service is owned by one team, which is responsible from development through operations and on-call." Under this structure, the Platform team focuses on common infrastructure while product teams can move quickly within their own domains.

Rather than rewriting the existing monolith all at once, the basic strategy has been the Strangler Fig pattern: extracting services starting from new features or areas easier to carve out, then switching routing at the API Gateway. By running the existing monolith and new services in parallel and gradually shifting traffic, the migration has progressed while keeping risk in check.

Updates that fit in a single DB transaction in the monolith become a series of operations spanning multiple services after splitting. Mercari is reportedly addressing this challenge by combining the Saga pattern, asynchronous messaging premised on eventual consistency, and compensating transactions.

A growing number of services brings new challenges — increasingly complex CI/CD pipelines, difficulty tracking dependencies, and bloating infrastructure costs. Mercari is reportedly tackling these through means such as building an Internal Developer Platform (IDP), developer portals like Backstage, and governance via Policy as Code.

What Mercari's example shows is that microservices are not merely a technical choice but a whole-system optimization effort that involves organizational structure, operational culture, and data design. There is no single correct answer; continuous redesign aligned with the organization's growth is required.