博士

ロボ子、今日のITニュースはTigerBeetleを使ったチケット販売ソリューションの話じゃぞ！

ロボ子

TigerBeetleですか、博士。初めて聞きました。どのようなものなのですか？

博士

TigerBeetleは、分散型の会計データベースみたいなものじゃな。今回の記事では、これを使ってチケット販売のデモを構築したらしいぞ。

ロボ子

なるほど。チケット販売に会計データベースを使うとは、面白い発想ですね。

博士

そうじゃろ！チケットを金融取引としてモデル化して、売り越しを防ぐために`DEBITS_MUST_NOT_EXCEED_CREDITS`制約を使ったらしいぞ。アーキテクチャレベルで売り越しを防ぐなんて、賢いのじゃ！

ロボ子

それはすごいですね。具体的には、どのように実装しているのでしょうか？

博士

各リソースに対して、Operator、Budget、Spentの3つのTigerBeetleアカウントを設定するらしいぞ。これで、チケットの種類ごとに予算と消費を管理できるのじゃ。

ロボ子

なるほど、予算と消費をアカウントで管理するのですね。アーキテクチャについても教えてください。

博士

FastAPI、SQLite、TigerBeetle、MockPayを使ったみたいじゃな。最初はSQLiteだったけど、PostgreSQLに移行したらしいぞ。最終的には、977件/秒のチケット予約を達成したみたいじゃ！

ロボ子

977件/秒ですか！すごいパフォーマンスですね。Oasisのチケット販売（65件/秒）を上回るとのことですが、どのようにしてそこまで改善したのでしょうか？

博士

最初はPostgreSQLがボトルネックになっていたから、Redisを導入してPostgreSQLを完全に置き換える実験をしたらしいぞ。最終的には、Redisをホットパス、PostgreSQLをコールドパスとして分離するアーキテクチャにしたみたいじゃ。

ロボ子

ホットパスとコールドパスを分離するのですね。それから、LiveBatcherを導入してTigerBeetleへのリクエストをバッチ処理したとのことですが、バッチ処理は効果的なのでしょうか？

博士

それが、シングルワーカー構成がバッチ処理の効率を高めることを発見したらしいぞ。バッチサイズは平均5-6件だったみたいじゃな。

ロボ子

シングルワーカー構成ですか。意外ですね。他にボトルネックになった点はありましたか？

博士

Pythonのイベントループのオーバーヘッドが全体の45%を占めていたらしいぞ。これは改善の余地がありそうじゃな。

ロボ子

なるほど。イベントループのオーバーヘッドですか。最適化は奥が深いですね。

博士

じゃろ？ちなみに、このTigerBeetleを活用したチケット販売ソリューションを異なる言語やスタックで実装して、パフォーマンスを競う「TigerBeetleチケットチャレンジ（TTC）」というのもあるらしいぞ。

ロボ子

面白そうですね！私も参加してみたいです。

博士

ロボ子ならきっと良い結果を出せるぞ！ちなみに、このデモは[tigerfans.io](https://tigerfans.io)で見れるみたいじゃ。ソースコードは[github.com/renerocksai/tigerfans](https://github.com/renerocksai/tigerfans)にあるみたいじゃから、見てみると良いぞ。

ロボ子

ありがとうございます、博士。後で確認してみます。

博士

しかし、977件/秒のチケット予約を達成したのに、私には一枚もチケットが回ってこないとは…これいかに！？

ロボ子

博士、それはシステムの問題ではなく、人気アーティストのチケット争奪戦に敗れただけだと思います…