チャットアプリのDB設計API設計と反省

とある技術課題を受けたけど落ちてしまったのでここで供養する。

課題内容

チャット機能を実装する。必要なテーブル/APIを設計し、APIドキュメント/テーブル仕様書を作成。

• LINEのように、1対1のチャットとグループチャット
• 基本的な投稿機能の他に、既読機能/通知機能/メッセージ削除機能が必要
• データベースはRDBのみを使う前提

余裕があれば以下の課題を追加で。

• ユーザーの数が膨大になり、パフォーマンスが落ちてきた際に、どのようなアプローチでそれを解消するか？

自分の解答

DB設計

API設計

フィードバック内容

以下の点で高負荷な環境を想定したシステム構築の経験が足りないと判断

• DBテーブルのPrimaryKeyに連番を設定しており代替案が無かった点
• Push通知送信機構をAPIセッションの中に持つ設計をしていた点
• 将来的にSQLとNoSQLを組み合わせた設計をすることが想定されていなかった点

DBテーブルのPrimaryKeyに連番を設定しており代替案が無かった

これについては口頭で説明した際に「オートインクリメントを使わない場合はuuidの使用が考えられますね」という会話をしていたのでなんだかなぁという感じです。

おそらく追加課題の出題者の想定するユーザー数増加の規模と自分の想定するユーザー数増加の規模が食い違っていたのかなと思います。
出題者としてはDBのシャーディングが必要な規模を初めから想定してDB設計をしてほしかったのかな？と。
で、僕はクエリの調整やコードの調整でなんとかできる程度の規模を想定していたので、そこでギャップが生まれたのかな？と思いました。

Push通知送信機構をAPIセッションの中に持つ設計をしていた点

これは完全に自分の調査不足・経験不足ですね。
他サービスを使うのに必要な情報は何か？まで調べて満足してしまい、他サービスのレスポンス速度まで想定するに至ってませんでした。
APIの中ではキューにいれて、非同期処理で他サービスに実行してPUSH通知を送る仕組みにするべきでした。

将来的にSQLとNoSQLを組み合わせた設計をすることが想定されていなかった点

これも自分の経験不足ですね。
NoSQLを使うという発想が出てこなかったですし、RDSとNoSQLを組み合わせてうまく運用している経験がなく、むしろRDS前提なのに他にもデータソースを用意するのは運用や処理がめんどくさくなる経験をしてきたので。
トランザクションなどの整合性を考えてRDSだけの運用しか考えてませんでした。

今でも、消えてもいいけど高速にしたいデータをRedisに保存するくらいしか思いつかないですね。ランキングとか。
自分でも調べていく必要があるし、むしろ誰か教えてほしいって感じです。

感想

課題自体は面白かったなと思います。
純粋なDB設計・API設計は綺麗にできていると思いますが、高負荷での想定や経験を伸ばしたいなと思いました。