予約の重複を、画面ではなくデータベースで止めた話

今日は、Next.jsとSupabaseで作っている宿泊・予約管理機能の「重複予約」を見直した。

画面では、登録前に同じ部屋・同じ期間の予約がないか確認していた。通常の操作なら十分に見えるが、ほぼ同時に2件の登録が走ると、両方の確認が「空いている」と判断してから保存へ進む可能性がある。管理画面で気をつけるだけでは、最後の一件を止められない。

そこで、重複判定を画面側だけに任せず、SupabaseのPostgreSQLにも制約を追加した。部屋と滞在期間が重なるデータは、どの入口から登録されても保存できない形にした。Next.js側では、PostgreSQLが返すエラーコード23P01をそのまま見せず、HTTP 409へ変換し、「同じ期間に別の滞在があります」と伝えるようにした。

実装で悩んだのは、強い制約を入れるほど運用中の例外処理が難しくなることだった。飛び込み客の手動登録、CSV取込、既存予約の編集も同じ条件を通るため、入口ごとに別ルールを作らず、データベースを最後の門番にした。そのうえで、通常登録、期間の一部重複、開始・終了が接するケースを分けて確認した。

業務システムでは、画面が正しく動くことと、データが壊れないことは別問題だと改めて感じた。便利な操作を増やす前に、重複を物理的に保存できない土台を作る判断が大切だった。

予約管理画面や業務システムの不具合調査、Next.js・TypeScript・Supabaseを使った改修についても、既存構成を確認しながら対応しています。「重複を防ぎたい」「小さく安全に直したい」といった段階からご相談ください。