DBのフォールバックとは？障害時にサービスを止めないための設計パターンと実装例

June 5, 2026

「DBが落ちたら全部止まる」、それ本当に仕方ない？

深夜にSlack通知が鳴る。「本番DBが応答しません」。ユーザーには500エラーの白い画面。復旧まで30分、その間の売上はゼロ。こんな経験、あるいは想像するだけでも胃が痛くなりますよね。

でも考えてみてください。DBが落ちた時に「何も返せない」のと「キャッシュから古いデータでも返せる」のでは、ユーザー体験がまるで違います。後者の考え方が、フォールバック（fallback）です。

本記事では、DBフォールバックの基本概念から、実務で使える3つの実装パターン、やってはいけないアンチパターンまでを解説します。

DBのフォールバックとは？ ― 障害時の「代替手段」で動き続ける仕組み

フォールバック（fallback）は、「fall（落ちる）」+「back（後ろに）」で、「本来の手段が使えない時に、代替手段に切り替える」という意味です。

【フォールバックなし】
リクエスト → DB問い合わせ → DB障害 → 500エラー → ユーザーに白い画面

【フォールバックあり】
リクエスト → DB問い合わせ → DB障害 → キャッシュから返す → ユーザーには古いけどデータが見える

完璧なデータを返せなくても、「何かしら返す」ことでサービスの体験を維持するのがフォールバックの目的です。100点が無理なら80点でいい、0点だけは避ける、という設計思想です。

どんな場面で必要？

フォールバックが効くのは、「多少古い・不完全なデータでもユーザーに価値がある」場面です。

場面	フォールバック	理由
商品一覧ページ	✅ 有効	5分前のデータでも表示できれば離脱を防げる
ダッシュボードの集計値	✅ 有効	リアルタイムでなくても直近の値で十分判断できる
決済処理	❌ 不適切	古いデータで決済すると二重課金や金額不整合のリスク
在庫数チェック	⚠️ 要検討	古い在庫数で受注すると欠品になるが、表示だけなら許容範囲

ポイントは、「読み取り」にはフォールバックが効きやすく、「書き込み」には慎重であるべきということ。決済や在庫確定のような整合性が必須の処理は、フォールバックではなくリトライやキューイングで対応するのが正解です。

フォールバックの3つの実装パターン

パターン1：キャッシュフォールバック（最も一般的）

正常時にキャッシュを更新しておき、DB障害時にはキャッシュから返す。Redisやインメモリキャッシュとの組み合わせが定番です。

// キャッシュフォールバックの基本パターン
import Redis from 'ioredis';
import { Pool } from 'pg';

const redis = new Redis();
const db = new Pool();

async function getProducts(): Promise {
  try {
    // 1. まずDBから最新データを取得
    const result = await db.query('SELECT * FROM products WHERE active = true');
    const products = result.rows;

    // 2. 成功したらキャッシュを更新（TTL 5分）
    await redis.set('products:active', JSON.stringify(products), 'EX', 300);

    return products;
  } catch (error) {
    console.error('DB query failed, falling back to cache:', error);

    // 3. DB障害時はキャッシュから返す
    const cached = await redis.get('products:active');
    if (cached) {
      return JSON.parse(cached);
    }

    // 4. キャッシュもなければエラー
    throw new Error('DB and cache both unavailable');
  }
}

この実装のポイントは、正常時に毎回キャッシュを更新していること。DB障害が起きた時にキャッシュが空だと意味がないので、「常にキャッシュを温めておく」のが重要です。

パターン2：リードレプリカフォールバック

プライマリDBが落ちた時に、リードレプリカ（読み取り専用の複製DB）に切り替えるパターン。キャッシュと違いデータの鮮度がほぼリアルタイムなのがメリットです。

// リードレプリカフォールバック
const primaryDb = new Pool({ host: 'db-primary.example.com' });
const replicaDb = new Pool({ host: 'db-replica.example.com' });

async function queryWithFallback(sql: string, params?: any[]) {
  try {
    return await primaryDb.query(sql, params);
  } catch (error) {
    console.warn('Primary DB failed, switching to replica:', error);
    return await replicaDb.query(sql, params);
  }
}

AWS RDSやAurora、Cloud SQLなど主要なマネージドDBサービスはリードレプリカを簡単に追加できます。コスト面でレプリカを常時稼働させる余裕があるなら、最も信頼性の高いフォールバック手段です。

パターン3：静的データフォールバック（最後の砦）

DBもキャッシュも死んだ場合の最終防衛線。JSONファイルやCDNに置いた静的データを返します。

// 静的データフォールバック（最後の砦）
import fallbackData from './fallback/products.json';

async function getProductsSafe(): Promise {
  try {
    return await getProductsFromDB();
  } catch {
    try {
      return await getProductsFromCache();
    } catch {
      // DB・キャッシュ全滅 → 静的データで最低限の表示を維持
      console.error('All sources failed, returning static fallback');
      return fallbackData;
    }
  }
}

ECサイトなら「定番商品だけでも表示する」、SaaSなら「メンテナンス中の案内ページを出す」など、0点を避けるための最低限のデータを用意しておくイメージです。