こんにちは。メルペイ Engineering Engagement チームの @mikichin です。 メルカリグループは「あらゆる価値を循環させ、あらゆる人の可能性を広げる」をミッションに、さまざまなサービスを展開しています。 メルペイは単なる決済サービスではなく、新しい「信用」を基盤として、それに基づく循環型社会、なめらかな社会を創ることを、メルコインはテクノロジーによって、さまざまな価値観の境界線を打ち破り、誰もが暗号資産・デジタル資産などあらゆる価値を簡単に交換できる世界の実現を目指しています。 そのためには、お客さま・企業・金融機関など、さまざまなステークホルダーに対して「OPENNESS」な姿勢で向き合うことで、もっと身近なものに変えていきたいと考えています。 本企画は、技術も「OPENNESS」にしていこうという考えのもと、2019年にスタートしました。 「Merpay & Mercoin Tech Openness Month 2026」では、メルペイ・メルコイン・メルカリモバイルの開発をしているエンジニアたちの取り組みをご紹介します。 各エンジニア組織がテクノロジーでお客さまの課題解決を実現することを大切にし、その挑戦の中で得た知見を6月1日から約1ヶ月間に渡り公開していきます！技術、開発設計や思想、組織ストラクチャー、Tips、その他最近の取り組みなど、幅広くお伝えします。 2019年は こちら 2020年は こちら 2021年は こちら 2022年は こちら 2023年は こちら 2025年は こちら ▼公開予定表 （こちらは、後日、各記事へのリンク集になります） Title Author GOPの100カ国展開を支えるPayment Platform @ryuyama AI と作る HTML ベースの LP エディタ EGP Code を作った理由 @mattsuu MySQLからSpannerに移行した時のQueryチューニング @sinmetal 決済プラットフォームと経理を繋ぐ MoneyFlow @komatsu TBD @hokao 事業者請求払いのための与信管理マイクロサービスの設計 @imamu 独立したカーソルを持つ複数データソースを統合するページネーション設計 @nanacom event駆動のチームにおいてpull型subscriptionを保ったままのPRRC環境の導入 @mikupo 内製ワークフローエンジンの設計とメルカリでの活用事例 @sapuri 初回ミーティングに開発完了した状態で臨むと超Move Fastになる @kubomi CloudFunction移行で1000万件滞留した話：PubSub × Cloud Run × Spannerのチューニング @mewuto 修正PRを食べてレビュースキルが賢くなる：Claude Codeによる自己改善サイクル @um（うめ） メルペイのキャンペーン基盤をルールベース汎用システムに書き直して Otoku Revolutionするまで — Santa Service の Rulebase 移行の話 @hasegway TiDB – BQ連携データパイプライン @orfeon About my AI work setup @cyan Product Engineerとして働く @anzai Otoku Revolutionのすべてをお話します @yutaro 任意の単位での債権の色付けと与信の分割を実現するDebt View @kobaryo TBD @abcdefuji Growth Platform体制の振り返り @yo-gawa Next Payment @haoyu TBD @Marlon どんな知見が得られるのか、毎日が楽しみです。 Merpay & Mercoin Tech Openness Month 2026 の1日目は、メルペイ Payment Platform @ryuyama が執筆予定です。 ひとつでも気になる記事がある方は、この記事をブックマークしておくか、 エンジニア向け公式X をフォロー＆チェックしてくださいね！

はじめに はじめまして。株式会社タップルでサーバーサイドエンジニアをしている糸井一颯( Issa ) ...

BUYMAのPersonal Shopper API（PS-API）が、gRPC、SQS、Webhook、非同期処理を活用して、マイクロサービスとモノリスをつなぎながらスケールする仕組みを紹介します。 こんにちは、エニグモのフェルナンドです。 SELLチームに所属し、出品者向け機能の開発を担当しています。 今回は、私たちのチームで運用している「PS-API」についてご紹介します。 日々増え続けるリクエストをどのように処理しているのか、そのアーキテクチャの裏側についてお話ししたいと思います。 👉 English version is also available below. BUYMAでは、パーソナルショッパー（出品者）が商品を出品する方法がいくつかあります。 マイページ から直接商品を登録する方法もあれば、 CSVインポート を使って一括登録する方法もあります。 さらに、自社システムを運用している大規模なパートナーや事業者向けには、 Personal Shopper API（通称：PS-API） を利用した連携手段も提供しています。 運用要件によっては、より深いカスタム連携を行うケースもあります。 これらの機能を利用する出品者が増えるにつれて、PS関連システムの保守・改善は、楽しくもあり、同時にとてもチャレンジングなものになっていきました。 出品方法の概要：My Page、CSVインポート、PS-API、カスタム連携 今回は、 PS-API について紹介します。PS-APIがどのように動いているのか、なぜ非同期APIとして設計したのか、そしてマイクロサービスと大規模なモノリスをつなぐシステムを運用する中で学んだリアルな教訓について共有します。 PS-APIの目的：BUYMAのコアプラットフォームへの連携レイヤー BUYMAはマーケットプレイスであり、商品登録は出品者にとって重要な日常業務のひとつです。 大量の商品を管理している出品者にとって、1件ずつ手動で商品を登録するのはとても大きな負担になります。 CSVインポートでその負担を減らすことができますが、在庫・価格・商品情報を自社システムで管理しているパートナーにとっては、API連携が自然な選択肢になります。 そこで登場するのがPS-APIです。 PS-APIでは、出品者が以下のような操作を行えます。 商品の登録・更新 在庫やバリエーションの管理 注文情報の取得 発送依頼の処理 PS-APIは、出品者側のシステムとBUYMAのコアプラットフォームをつなぐ、強固な連携レイヤーとして機能しています。 PS-APIは、出品者システムとBUYMAのコアプラットフォームをつなぐ連携レイヤー 課題：マイクロサービスと既存モノリスの連携 BUYMAの主要な業務処理の多くは、現在もメイン環境、つまり巨大なモノリシックなシステム上で動いています。 一方で、PS-APIはモダンなマイクロサービスとして実装されています。 私は以前にサーバーレス開発の経験はありましたが、大規模なマイクロサービスアーキテクチャに本格的に関わるのはこれが初めてでした。 キュー、ワーカー、リトライ、サービス間通信、Webhook配信といった分散システムの世界に入っていくのは、本当に、とても勉強になりました。 PS-APIとBUYMAメインシステムのアーキテクチャ概要 ※ アーキテクチャは、おおまかに言うとこのような構成になっています。 ここで重要な設計思想は次の点です。 PS-APIは最終的な処理先ではない 外部システムとBUYMAのモノリスをつなぐ「オーケストレーションレイヤー」である なぜ非同期処理なのか PS-APIにおける最大の設計判断のひとつが、多くの処理を非同期にしたことです。 出品者が商品登録リクエストを送信した場合、システムはすべての処理を同期的に実行して、最終結果を即時で返すわけではありません。 代わりに、次のような流れをたどります。 リクエストを受け付ける 処理用のキューに積む（即時レスポンス） BUYMA側で後続処理を行う（ワーカーによる非同期処理） 最終結果をWebhookで返す この方式には、決定的なメリットがあります。 1. トラフィックスパイクの吸収 出品者は、ときどき大量のリクエストを一斉に送信します。 ここで言う「大量」とは、監視ダッシュボードが悲鳴を上げるレベルの量です。 非同期キューを使うことで、急激なトラフィック増加をそのままコアシステムに流し込むのではなく、一度バッファとして受け止めることができます。 リクエストは順番を待ち、システムが耐えられる制御されたペースで処理されます。 最終的な商品登録処理がBUYMAのメインシステムに依存しているため、このバッファリング層は非常に重要な役割を担っています。 非同期キューにより、外部からの大量リクエストを一度バッファリングする 2. 障害時のグレースフル・デグラデーション（確実なリカバリー） 下流システムが一時的に利用できない場合でも、出品者が同じリクエストを手動で再送する必要はありません。 リクエストは安全にキューに残り、下流システムが復旧したあとに自動で処理を再開できます。 ユーザーに「成功するまで何度もリトライしてください」とお願いするより、はるかに健全です。 アプリへの信頼を完全に失ってしまう前、システム側で吸収できることは吸収すべきです。 3. コアプラットフォームの保護 商品登録や注文関連の主要な処理は、BUYMAのモノリシックなメイン環境で実行されています。 そのため、このコアシステムを過負荷から慎重に保護する必要があります。 PS-APIが外部トラフィックを受け止め、モノリス側へリクエストを渡すペース（スループット）を制御します。 これは、マイクロサービスの柔軟性と、モノリスの安定性を両立するための設計です。 gRPCとSQS：通信方式の適材適所 PS-APIでは、すべての通信を同じ方法で扱っているわけではありません。 処理の性質、つまり即時性が必要か、耐久性が必要かに応じて、gRPCとAmazon SQSを明確に使い分けています。 gRPC gRPCは主に、即時のレスポンスが必要な内部サービス間通信で利用しています。 これは、PS-APIが現在の処理を続行する前に、信頼できる内部レスポンスを必要とするケースです。 たとえば、以下のような用途で使っています。 パートナーシステムとLive PS-API間の通信 パートナーシステムとSandbox PS-API間の通信 ブランド情報やカテゴリ情報などのマスターデータ取得 SQS 一方で、より重い業務処理にはSQSベースの非同期処理を利用しています。 たとえば、BUYMAのメインシステムと連携する以下のような処理です。 商品登録・更新 注文の発送依頼処理 なぜこの設計がうまく機能するのか gRPCとSQSを組み合わせることで、それぞれの通信方式を多様な場面で使うことができます。 gRPCは、高速な内部リクエスト・レスポンス通信に、SQSは、耐久性のある非同期業務処理に使います。 特徴 gRPC SQS（非同期キュー） 主な用途 内部サービス間の直接通信 重い業務処理、モノリス連携 処理モデル 同期的（即時レスポンス待ち） 非同期的（Event-Driven） メリット 高速、型安全（Protobuf）、明確な契約 耐久性、リトライ容易、スパイク吸収 具体例 マスターデータ（ブランド/カテゴリ）取得 商品の登録・更新、発送依頼処理 SQSとWebhookによる非同期ループの完成 重い処理はSQSを利用します。リクエストを受け付けると、ペイロードを保存し、その後の業務処理をワーカーが非同期で進めます。 重要なのは、SQSは「処理の完了イベント」にも利用されている点です。 商品登録が完了すると、その結果がキュー経由でPS-APIに返され、そこから出品者へWebhookレスポンスが送信されます。 Webhookは単なるAPIの即時レスポンスではなく、非同期処理の最終通知なのです。 gRPC、SQS、WebhookによるPS-APIの通信フロー この区別には、いくつかのメリットがあります。 BUYMAのメインシステムを急激なトラフィック増加から保護できる 多くの出品者が同時に商品更新リクエストを送った場合でも、リクエストをキューに積み、段階的に処理できます。 信頼性が向上する 下流システムの一部が一時的に利用できない場合でも、リクエストが消えてしまうことはなく、出品者がすべてを手動で再試行する必要もありません。 スケールしやすい基盤になる APIリクエストの受付、キュー処理、Webhook配信をそれぞれ個別に改善できます。 本当の課題：スケール PS-APIは当初、小規模なユースケースを想定して設計されていたため、現在のトラフィック規模にはそぐわなくなっています。 サービスの普及に伴い、APIを利用する出品者数とリクエスト数が急増しました。このスケールアップに伴い、スケーラビリティや運用面でいくつかの課題が表面化してきました。 レートリミット キューのボトルネック 処理状況の可視性 「リクエストは成功したのに、商品はどこにありますか？」という問い合わせ この最後の質問に対する答えは、時々こうなります。 “技術的には……まだキューのどこかにあります。” または、 “Webhookはエラーメッセージ付きで送信されました。” 非同期システムの運用は、設計するよりもずっと面白くなってくるのがこのあたりです。 APIを作ること自体ももちろん大変です。 しかし、リクエストが今どの処理段階にあるのかを、関係者全員が理解できるようにすることは、また別の難しさがあります。 そして多くの場合、後者の方が難しいです。 非同期システムに潜む複雑さ 外から見ると、APIリクエストはとてもシンプルに見えます。 POST /api/v1/products.json しかし内部では、実際には以下のような複雑なパイプラインが走っています。 API → バリデーション → データベース → キュー → ワーカー → ストレージ → 画像ダウンロード → 後続処理（または「下流プロセッサ」） → 完了イベント → キャッシュ無効化 → Webhook配信 APIは、単なるエンドポイントというより、空港の手荷物管理システムのようになっていきます。 システムは信頼されている。でも、リクエストが今どこにあるのかを完全に把握するのは難しい――そんな世界です。 オンプレミスからAWSへの移行 出品処理におけるデータベースのトランザクション速度を改善するうえで、大きな転機となったのがインフラのAWS移行とDBアップグレードです。AWSのリソースを活用することで、DB接続の安定性や処理性能が向上し、インポート速度も改善されました。 もちろん、AWSへ移行したりDBをアップグレードしたりしたからといって、すべてのボトルネックが簡単に消えるわけではありません。それでも、DB接続の安定性やトランザクション処理速度の改善は、非同期処理全体のパフォーマンスに大きく影響します。 今後も改善していくこと：本当の「スケール」に向けて PS-APIはもともと少数のユーザーを想定して作られていましたが、その想定も今は昔です。 現在も、出品者が安心して運用を任せられる強固な基盤を目指し、以下の領域を継続的に改善しています。 より良いレートリミット戦略の実装 リクエスト状態の可視性向上 画像ダウンロード処理の高速化とワーカーのオートスケーリング 技術的な専門知識がない出品者でも、スムーズに連携を開始できるようPS-APIドキュメントを拡充 モノリスとマイクロサービスをまたぐ運用の改善 私たちの目標は、単に大量のリクエストを「受け付ける」ことではありません。 数千件規模のスパイクにも安定して対応し、出品者のビジネスを裏から確実に支える、真に信頼できるAPIシステムへ進化させ続けることです。 注記: 本記事内の画像は、内容をわかりやすく表現するためにAIで生成したイメージ画像です。 Building for Scale: Inside the Event-Driven Architecture of the BUYMA Personal Shopper API Good day, I’m Fernand from Enigmo. I’m part of the SELL team, where I work on developing features that support sellers. This time, I’d like to talk about “PS-API,” a system operated by our team. I’ll share some insights into the architecture behind it and how we handle the continuously growing number of requests every day. At BUYMA, personal shoppers have several ways to list products on the platform. Some sellers manage listings directly from My Page . Others use CSV import for bulk operations. For larger partners and businesses that operate their own systems, we also provide integration options through the Personal Shopper API , or PS-API. In some cases, we even support deeper custom integrations depending on the seller’s operational needs. As more sellers began using these features, maintaining and improving the PS systems became both fun and challenging. Listing options: My Page, CSV import, PS-API, and custom integrations This time, I would like to introduce PS-API : how it works, why we designed it as an asynchronous API, and what we learned from operating a system that connects a microservice with a large monolithic platform. Purpose of PS-API BUYMA is a marketplace where product registration is one of the most important daily operations for sellers. For sellers managing large catalogs, manually listing products one by one quickly becomes painful. CSV import helps, but for partners that already manage inventory, pricing, and stock through their own systems, API integration becomes the natural next step. That is where PS-API comes in. It allows sellers to: create and update products manage stock and variants receive order information handle shipment requests PS-API acts as an integration layer between personal shoppers’ systems and BUYMA’s core platform. PS-API connects seller systems with BUYMA’s core platform The Challenge: When a Microservice Meets a Monolith Most of BUYMA’s core business processes still run in the main environment, which is a monolithic system. PS-API, however, was implemented as a microservice. Although I had experience with serverless development before, this was my first time working on a microservice architecture. Moving into a world of queues, workers, retries, internal service communication, and webhook delivery was very educational. Very educational... ※ The architecture looks something like this. High-level architecture of PS-API and BUYMA’s main system The key point here is: PS-API is not the final destination. It is the orchestration layer between external personal shopper systems and BUYMA’s platform. Why Asynchronous Processing One of the biggest design decisions in PS-API was to make many operations asynchronous. When a seller sends a product registration request, the system does not process everything synchronously and immediately return the final result. Instead: The request is accepted. It is queued for processing. BUYMA processes it downstream. The final result is sent back via webhook. This approach gives us several important advantages. 1. Handling Traffic Spikes Sellers sometimes send bulk requests. And by “bulk,” I mean enough requests to make the monitoring dashboard emotionally unavailable. With asynchronous queues, sudden traffic spikes can be absorbed without immediately overwhelming the core system. Requests can wait in the queue and be processed at a controlled pace. This is especially important because the final product registration still depends on BUYMA’s main system. synchronous queues buffer sudden request spikes before they reach the core platform 2. Better Failure Recovery If a downstream system is temporarily unavailable, sellers do not need to resend the same request manually. The request can remain in the queue, and processing can resume once the downstream system recovers. This is much better than asking users to keep retrying until they lose faith in the service entirely. 3. Protecting the Core Platform Because the main product registration and order processes still happen inside BUYMA’s monolithic environment, we need to protect that system carefully. PS-API absorbs external traffic and controls how requests are passed to the core platform. This allows the monolith to process requests at a safer and more predictable pace. Microservice optimism meets monolith realism. gRPC and SQS: Choosing the Right Communication Style In PS-API, not all communication is handled in the same way. Some processes require quick, direct communication between internal services. Other processes need durable asynchronous execution because they may take longer, depend on the BUYMA core platform, or require retries. For that reason, we use both gRPC and SQS, depending on the characteristics of each process. gRPC We mainly use gRPC for internal service-to-service communication where an immediate response is required. These are cases where PS-API needs a reliable internal response before continuing the current process. BUYMA Partners System ↔ Live PS-API communication BUYMA Partners System ↔ Sandbox PS-API communication Retrieving master data, such as brand data and category data Using gRPC gives us several advantages: fast internal communication clear service contracts through protobuf definitions better type safety between services predictable request-response behavior SQS For heavier business operations, we use SQS-based asynchronous processing. This includes communication with BUYMA’s main system for operations such as: product listing and update order shipment request processing These operations eventually affect BUYMA’s core platform, where product and order data are actually processed. Instead of forcing the original API request to wait until all downstream processing is complete, PS-API accepts the request, stores the payload, and lets the business process continue asynchronously. SQS is also used for process completion events. For example, after product listing or product update processing is completed, the completion result is sent back through the queue. PS-API then imports the result and sends the appropriate webhook response to the seller system. This is an important point: webhook delivery is not simply a response to the original API request. It is the final notification after asynchronous processing has completed. gRPC, SQS, and Webhook complete the asynchronous processing loop Why This Design Works Well Using gRPC and SQS together allows each communication pattern to be used where it fits best. gRPC is used for fast internal request-response communication. SQS is used for durable asynchronous business processing. This separation gives us several benefits. It protects BUYMA’s main system from sudden traffic spikes. If many sellers send product update requests at the same time, those requests can be queued and processed gradually. It improves reliability. If part of the downstream system is temporarily unavailable, requests do not simply disappear, and sellers do not need to retry everything manually. It gives us a better foundation for scaling. API request handling, queue processing, and webhook delivery can each be improved separately. This combination is one of the key reasons PS-API can operate as a bridge between external seller systems and BUYMA’s existing core platform. The Real Challenge: Scale Originally, PS-API was intended for a relatively small number of users. That assumption aged beautifully. As adoption increased, both the number of sellers and the number of requests grew significantly. With that growth came several familiar challenges: rate limits queue bottlenecks processing visibility issues inquiries like “The request succeeded, but where is my product?” The answer to that last question is sometimes: "Technically… somewhere in the queue." Or: "The webhook was already sent, along with an error message." This is where operating asynchronous systems becomes much more interesting than designing them. Building the API is one thing. Helping everyone understand the flow of request is another. And usually, that is the harder part. The Hidden Complexity of Async Systems From the outside, an API request may look simple: POST /api/v1/products.json But internally, the flow may look more like this: API → validation → database → queue → worker → storage → image download → downstream processor → completion event → cache invalidation → webhook delivery At some point, API starts looking less like an endpoint and more like airport baggage handling. Everyone trusts the system. No one is entirely sure where the suitcase is. From On-Premise to AWS One major improvement came from moving our infrastructure from on-premise servers to AWS, along with upgrading the database. This improved the transaction speed of import-related database operations. Of course, moving to AWS and upgrading the database did not magically remove every bottleneck. Software remains committed to teaching humility. However, it gave us a much stronger foundation, especially for asynchronous processing. For systems that depend heavily on queues, workers, and scalable processing capacity, infrastructure flexibility matters a lot. What We Are Still Improving Even after these improvements, scalability remains an ongoing challenge. The API layer can scale relatively well, but many core processes still depend on the main environment, where scaling is naturally more difficult. We are continuing to improve areas such as: better rate-limit strategies faster image download processing autoscaling for workers better visibility into request status smoother operations across monolith and microservice boundaries expanded PS-API documentation so that even sellers without technical expertise can smoothly start integrating with the platform The goal is not simply to accept the request. The real goal is to make PS-API a system sellers can rely on and one that can handle thousands of requests. Note: The images in this article were created using AI-generated visuals and are intended for conceptual illustration. hrmos.co