PayPayのリアルタイム決済の仕組みを考えてみた

リアルタイム決済を支えるシステム設計

1. はじめに

私はいつも疑問に思っていました。スマホをかざすと聞こえるあの「PayPay!」という音。
皆さんも考えたことありませんか、「なんであの一瞬で決済が成り立つのだろう」と。
実はこのわずか1秒にも満たない体験の裏で、高負荷な決済処理がリアルタイムで行われていることはご存知でしょうか？

PayPayは国内最大規模のQRコード決済サービスであり、ピーク時には1秒あたり数千件の決済を処理します。にもかかわらず、ユーザー体験は一貫してスムーズです。

本記事では、PayPayの裏側にあるリアルタイム決済基盤のアーキテクチャ設計に迫ります。

2. リアルタイム決済の技術的課題

まずは決済サービスをリアルタイムに成立させるための技術的課題について考えてみましょう。
サービスを成立させるために以下のような複雑な課題を同時に解けるようにする必要があります。

• 高トラフィック耐性: 数千TPS(transactions per second)を捌くスケーラビリティ
• 整合性保証： 二重決済を絶対に起こさない
• レイテンシ低減： 即時に残高反映し、音を鳴らす体験
• 堅牢なセキュリティ： 不正や改ざんを即検知する

特にユーザーが支払った直後に「PayPay!」と音を鳴らすには低レイテンシな設計と順序整合性の工夫が不可欠です。

3. PayPayの基本設計（あくまでも予測ですが、、）

PayPayのリアルタイム決済体験を支えるアーキテクチャは、マイクロサービス＋イベント駆動型アーキテクチャだと考えられます。

以下のようなアーキテクチャを作成してみました。順次それぞれの層の役割について考察していきたいと思います。

BFF層：即時レスポンスの要

もしかしたらあまりなじみのない言葉かもしれませんが、BFF(バックエンドフォーフロントエンド)とはマイクロサービスアーキテクチャにおいてクライアントとバックエンドの中間に位置し双方の複雑性を吸収するような作られたサーバーのことです。

この層でユーザーのリクエストを受け取り、認証・ルーティング・APIレスポンス整形などを担っています。マイクロサービスの複雑な構成を抽象化し、ユーザーに常に安定したレスポンスを返す設計がなされています。

A. 決済マイクロサービス(手前側)：状態生成の中核

BFFからのリクエストを受ける層です。この時点で必要最低限の状態検証（例：残高確認、二重決済チェック）を行い、処理結果をKafkaに「イベント」として送信します。

主な責務としては以下のようなものがあります。

• リクエストのバリデーション（例：署名チェック、セッション確認）
• 残高の確認（ただし最終的な更新はしない）
• 二重決済の検出（同一取引IDの多重処理をガード）
• 処理の成功 or 失敗を即座にレスポンス
• 成功した場合は Kafka に「支払いイベント（PaymentRequestedなど）」を publish

ここではまだDBには直接書き込まず、Kafkaにpublishするだけというのが大きなポイントです。

Kafka:非同期化と疎結合の鍵

Kafkaは、リアルタイム決済における並列性・耐障害性・拡張性を実現する中核です。

• 決済サービスが「支払いイベント」をpublish
• 残高更新、通知送信、取引記録、モニタリングなどがそれぞれ非同期にsubscribe
• 各処理は並列に動くため、即応性が高く、ボトルネックになりにくい

この構造によって、「PayPay!」という通知音も支払いの即時性を保ったまま非同期に処理されます。

B. 非同期のワーカー群

この層が、Kafkaのトピックをsubscribeして処理を進める非同期のワーカー群です。

主な責務としては以下のようなものがあります。

• 残高MS： 残高の減算・トランザクションのロールバック処理
• 通知MS： 支払音や通知Pushの送信
• 監視MS： 不正検知用にログを解析
• 記録MS： 会計・監査用の取引履歴DBに保存

4. イベント駆動設計の強み

PayPayの大規模な決済処理において鍵となっているのがイベント駆動型アーキテクチャ（EDA）です。
PayPayでは、ユーザーが支払うと「決済完了」などのイベントが即座にKaflaにpublishされ、それを購読する複数の独立したユーザーが非同期に処理を行います。

これにより、以下のような技術的利点が得られます。

• スケーラビリティ：購読側サービスは水平スケール可能。トラフィック急増時も独立に拡張
• 疎結合な構造：ある処理が遅延しても他のサービスに影響を与えずに済む
• 再処理と障害回復：Kafkaのログ保持性により、障害発生時にもリトライ可能
• 追加機能の柔軟性：例えば「キャンペーン集計」や「不正検知」などの新機能を、Kafkaのイベントを購読するだけで既存コードに手を加えずに追加可能

EDAは、単に「非同期にする」という技術的選択ではなく、「変化に強い設計の骨格」として機能しています。
決済のようなミッションクリティカルで変更が頻発する領域において、その恩恵は計り知れません。

5. UXとバックエンドが一致する設計とは？

別の視点でPayPayが優れているところとして、「非同期処理でありながら、あたかもリアルタイムに動いているように見せる工夫」があります。

例えば：

• 決済完了前にサウンドを予約再生
• UI上は"残高反映済み"に見せつつ、内部では最終整合性を担保
• 失敗時は即座に巻き戻す仕組み（逆取引イベント）

このようにUXとバックエンドが綿密に連動することで、リアルタイムに感じるけど堅牢という理想的な決済体験が実現しています。

6. まとめと考察

PayPayは単なる決済アプリではなく、「リアルタイムで動く大規模な分散処理システム」とエンジニアは捉えたほうがよいでしょう。

このようなリアルタイム性と信頼性の両立には、高度な設計思想と実装力が求められます。それを支えているのが、現代的なマイクロサービス群と疎結合な非同期アーキテクチャです。

PayPayだけでなくメルペイなども日本を代表する決済システムであるのでそれぞれがどう違っているのか調べてみると面白いかもですね。