01 · 課題
本来は別々のはずの3つの製品、チケット販売、有料コンテンツ、複数出品者のマーケットプレイスを一つのアプリに収めました。どれもお金が動き、それぞれ「いつお金が動いたとみなすか」のルールが異なります。チケットは前払いで当日に引き換え、コンテンツは一度解放されればそのまま、注文は商品が届いて初めて確定。それでも一つのアカウントの中では、一つの履歴として読めなければなりません。
実績 04 / 08
アニメ・コスプレコミュニティ向けスーパーアプリのバックエンド開発。イベントのチケット販売、クリエイターの有料コンテンツ、複数出品者のマーケットプレイス。
ケーススタディ
本来は別々のはずの3つの製品、チケット販売、有料コンテンツ、複数出品者のマーケットプレイスを一つのアプリに収めました。どれもお金が動き、それぞれ「いつお金が動いたとみなすか」のルールが異なります。チケットは前払いで当日に引き換え、コンテンツは一度解放されればそのまま、注文は商品が届いて初めて確定。それでも一つのアカウントの中では、一つの履歴として読めなければなりません。
ここで重要なのは機能の数ではなく、バックエンドが守るべき境界です。出品者の在庫やチケットの枠は有限で、二人の購入者が同じ1秒に取り合うことがあります。その競合はデータベースで決着させなければなりません。アプリケーション層は同時に複数プロセスで動くことがあり、そこでのチェックは隣のプロセスを見られないからです。さらにお金には追跡可能な履歴が必要です。後で必ず聞かれるのは「今の状態」ではなく、「いつ、何にもとづいて状態が変わったか」です。