API・データベースの記事
- インデックスはEXPLAINで確かめる — 複合インデックスの順序と効かない書き方 「検索に使う列だからインデックスを張った」だけでは、そのインデックスが使われているかは分かりません。複合インデックスの列の順序の決め方、インデックスが効かなくなるクエリの書き方、EXPLAIN の読み方と、レビューで確かめる点を Laravel と MySQL の例でまとめます。
- Rate Limiterは何を単位に制限するか — 利用者・IP・対象と429の返し方 Laravel の throttle を既定のまま使うと、NAT の後ろの利用者がまとめて 429 になったり、ログインの総当たりを止められなかったりします。制限の目的から数える単位を決め、制限したときの応答と、Redis が使えないときの振る舞いまでを Laravel の例でまとめます。
- ページネーションはoffsetかcursorか — 件数・並び順・API互換性から決める 一覧の API を offset で作ると、件数が増えたときに深いページが遅くなり、ページをめくる間の追加や削除で行が重複したり抜けたりします。並び順を一意にする前提と、offset と cursor の使い分け、カーソルの中身と API の形の決め方を Laravel の例でまとめます。
- 楽観ロックと悲観ロックの使い分け — versionカラムと衝突の見せ方 同じ行を2つの処理が読んで書き戻すと、先に書いた更新が黙って消えます。version カラムによる楽観ロック、SELECT ... FOR UPDATE による悲観ロック、条件付きの UPDATE を、衝突の頻度と利用者への見せ方から使い分ける考え方を、Laravel の例でまとめます。
- 外部APIのタイムアウトとリトライ設計 — 再送してよい失敗の見分け方 外部APIの呼び出しにタイムアウトを設定せず、失敗したら何でもリトライする設計は、障害を広げたり二重実行を起こしたりします。タイムアウトの決め方、リトライしてよい失敗といけない失敗の見分け方、指数バックオフの置き場所をLaravelの例でまとめます。
- クライアントアプリを壊さないAPI変更とリリース順序の考え方 モバイルアプリなど更新をすぐ強制できないクライアントがあるAPIでは、サーバー側の変更がそのまま障害になります。後方互換性を保つ変更の進め方、デプロイ順序、ロールバックできるかの確認ポイントを整理します。
- 冪等性が必要な処理の見分け方と、Idempotency Keyによる実装 ネットワークの再送、ボタンの連打、キューのリトライで、同じ処理が2回実行されることは避けられません。冪等性が必要な処理の見分け方と、Idempotency Key・一意制約・状態遷移のチェックを使った実装、その限界をまとめます。