ID:42407さん

#### 配送ネットワーク自動切り替え機能の設計・実装（2025） ##### 概要 - 配送プラットフォームにおいて、外部配送ネットワーク（Wolt、Uber Direct、Menu）への自動フェイルオーバー機構を設計・実装 - 1つのネットワークでマッチングがタイムアウトした場合、次候補へ自動切り替えして配送成功率を向上 ##### 担当範囲 - 要件定義、設計、実装、テスト、リリースまで一貫して担当 ##### 課題・問題点 - Wolt → Menu → Uber Direct と順番に試行する際、「どのネットワークで現在募集中か」「どのネットワークは試行済みか」を正確に管理する必要がある - ネットワーク切り替え時のイベント（募集開始、マッチング、キャンセル等）を記録し、運用時に追跡可能にする必要がある ##### 最終的に選んだ案、決め手 - 状態管理: 各ネットワークに募集ステータス（`not_recruited`, `recruiting`, `matched`, `cancelled`）を持たせ、「選択されたネットワーク一覧」から「試行済みネットワーク」を引き算して次候補を算出する方式を採用。これにより外部API障害時も正しい状態を維持できる - イベントログ: 配送ライフサイクル全体（募集開始、マッチング成功/失敗、キャンセル等）をDBに記録し、管理画面から参照可能にした。ログ記録失敗時はメイン処理をブロックせずSentry通知のみ行う設計とした ##### 実装時の工夫 - 自動切り替え基盤 → イベントログ記録 → タイムアウト時間の組織単位設定、と段階的にリリースしてリスクを最小化した

##### 概要 - 在庫管理アプリケーションzaicoでは現在の在庫数量と将来の入庫予定・出庫予定の数量を別々のテーブルで管理していた。 - 現在の在庫数量に将来の入庫予定・出庫予定の数量を加味した新しい数量（論理在庫と呼ぶ）を管理できるようにする。 ##### 設計について検討したこと - 論理在庫を新しいテーブルとして管理するか？ - それとも在庫テーブルにカラム追加するか？ - もしくはカラム追加せず、表示するときに毎回計算するようにするか？ - 性能懸念はないか？ など ##### 課題・問題点 - 在庫テーブルは数千万件のレコードを持っており、適切に扱わないと性能懸念がある - 在庫テーブルはアプリの根幹となるテーブルであり、安易に手を加えるのはリスクがある - またzaicoはWebアプリだけでなくモバイルアプリもあるのでそれらの整合性を考慮する必要がある など ##### 最終的に選んだ案、決め手 - 毎回計算する方法だと在庫件数が多い場合の性能低下が無視できないことが判明したので在庫テーブルにカラムを追加する方法を選択した - ただしカラム追加時のALTER実行時に1時間程度時間がかかることが判明したので、メンテナンス時間を設けた - またモバイル対応は後から行うことにし、まずはwebから開発・リリースすることでリスクを抑えた ##### 実装時の工夫 手戻りの少ないように先に画面側のモックを作成し、関係者と認識を合わせておくことで手戻りのリスクを低くした。