収録問題 70問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
決済作成APIで、クライアントが応答を受け取れず同じ要求を再送しても二重決済を防ぎたい。適切な設計はどれですか？
答え： 冪等性キーを保存し同じ要求には以前の結果を返す
冪等性キーを業務結果と関連付けて原子的に保存すると、応答喪失後の再送を新規処理せず以前の結果へ対応付けられます。キーの有効期限と、同一キーで内容が異なる場合の拒否も定義します。
公開APIへ必須フィールドを追加したい。既存クライアントを壊しにくい変更方法はどれですか？
答え： 任意で追加し既定動作を整えてから新バージョンで必須化する
API変更はadditiveかつ後方互換に進め、利用状況を計測しながら移行期間を設けます。契約を破る変更は明示的な新バージョンと廃止計画で扱います。
更新が多い大規模データをAPIでページングする。深いOFFSETの遅延とページ間の重複を抑える方法はどれですか？
答え： 安定した一意順と最後のキーを含むカーソルを使う
作成時刻とIDなどによる一意な順序を決め、前ページ末尾より後を取得するkeyset方式ならインデックスSeekを利用しやすく、途中挿入の影響も抑えられます。
API利用者ごとの短時間バーストを許容しつつ、平均要求率を制限したい。適切な方式はどれですか？
答え： トークンバケットを使い超過時は429とRetry-Afterを返す
トークンバケットは一定速度でトークンを補充し、蓄積分だけバーストを許可します。制限単位を利用者・APIキー・テナントなどで定義し、429と再試行目安を返します。
上流APIの残り応答時間が800msで、下流サービスを二つ順番に呼ぶ。適切なタイムアウト設計はどれですか？
答え： 全体デッドラインを伝播し各呼出しに残り時間未満の予算を割る
入口で決めたデッドラインを伝播し、ネットワークや後処理の余白を引いて下流へ予算配分します。期限超過時は不要な処理をキャンセルし、資源を解放します。
一時的な503に対する再試行で、障害中サービスへの同時集中を避ける方法はどれですか？
答え： 回数を制限しジッター付きバックオフで冪等操作だけ再試行する
指数バックオフは試行間隔を広げ、ジッターはクライアント間の同期を崩します。再試行対象、総時間、回数を制限し、非冪等操作には冪等性制御が必要です。
下流サービスが連続失敗している間、呼出し元の資源を守り、回復確認も行いたい。適切な仕組みはどれですか？
答え： サーキットブレーカーで早期失敗しHalf-Openで少数試行する
サーキットブレーカーは失敗率などでオープンとなり、失敗が明らかな呼出しを短絡します。待機後のHalf-Open試行で回復を確認し、成功すればClosedへ戻します。
低優先度の帳票APIが接続プールを使い切り、重要な決済APIまで停止することを防ぎたい。適切な設計はどれですか？
答え： 機能ごとに接続や同時実行枠を分けるバルクヘッドを設ける
Bulkheadは船の隔壁のように資源を分離し、一機能の飽和を他機能へ波及させません。重要度に応じてプールやSemaphoreの上限を設定します。
コンシューマー処理能力を超えるイベントが流入している。メモリ枯渇を避けるバックプレッシャー設計はどれですか？
答え： 上限付きキューと流量制御で抑制・拒否の方針を定める
容量を有限にし、満杯時の挙動をAPI・ブローカー・Reactiveストリームの契約として定義します。重要度に応じて429、プロデューサー待機、キューイング、負荷制限を使い分けます。
依存DBが停止した際、Podを再起動し続けずトラフィックだけを外したい。プローブ設計はどれですか？
答え： プロセスの健全性はliveness、受付可否はreadinessで分ける
livenessは再起動で回復できるプロセス異常、readinessは現在要求を処理できるかを表します。共有DB障害は通常Pod再起動では直らないため、readinessで切り離します。
ネットワーク分断中も二つのリージョンで書込みを受け付ける設計を選ぶとき、CAPの観点で受け入れる必要があるものはどれですか？
答え： 一時的な不整合と復旧後の競合解決が必要になる
分断耐性（Partition Tolerance）が必要な状況で両側の可用性を維持すると、互いの更新を即時確認できず強いConsistencyを同時には保証できません。競合検出・解決規則を業務に合わせて設計します。
注文更新直後に同じ利用者が参照すると古いレプリカ値が見える。Read-your-writesを提供する方法はどれですか？
答え： 更新後しばらくプライマリへ送るか追随済みレプリカを待つ
書込みで得たバージョンやLSNをセッションへ保持し、その位置まで追随したレプリカを選ぶかプライマリを読むと、その利用者の直前更新を観測できます。
注文、決済、在庫を別サービスが管理する。分散トランザクションを使わず業務全体の失敗を扱う設計はどれですか？
答え： Sagaでローカルトランザクションを連鎖し補償処理を定義する
Sagaは各サービスのローカルトランザクションとイベントまたはコマンドを組み合わせ、後続失敗時に返金・在庫解放など意味上の補償を実行します。補償自体の冪等性も必要です。
DB更新は成功したがイベントブローカーへの送信だけ失敗する二重書込み問題を防ぎたい。適切なパターンはどれですか？
答え： 業務更新とアウトボックス行を同じトランザクションで保存し後から中継する
Transactionalアウトボックスはイベント送信予定を業務データと原子的にコミットします。Relayは未送信行を再試行できるため、コンシューマー側の冪等性と組み合わせて欠落を防ぎます。
ブローカーが同じイベントを再配信しても副作用を一度だけにしたい。コンシューマー設計はどれですか？
答え： イベントIDに一意制約を設け処理済み記録と更新を原子的に保存する
At-least-once配送では重複を正常系として扱います。永続的な重複排除キーと業務更新を同じトランザクションへ含めれば、クラッシュやACK喪失後の再配信にも耐えられます。
ブローカーがExactly-once配送を掲げている場合でも、外部DB更新に冪等性が必要な理由はどれですか？
答え： ブローカーの保証は外部DBとの原子性を含まず再処理が起こり得るから
保証範囲を明確にします。ブローカー内トランザクションや重複排除があっても、外部DBコミット後・ACK前のクラッシュなどでは処理が再開されるため、業務副作用を冪等にします。
顧客ごとの注文イベント順序を維持しつつ、顧客間は並列処理したい。パーティションキーは何にすべきですか？
答え： 顧客を識別するcustomerId
同じcustomerIdを同じパーティションへルーティングすれば、その顧客の順序をパーティション内で保ちつつ、異なる顧客は複数パーティションで並列化できます。ホットキー分布も監視します。
同じメッセージが繰り返し失敗しキュー先頭を塞いでいる。適切な運用はどれですか？
答え： 上限回数後にDLQへ隔離し原因調査と再投入手順を整える
Poisonメッセージは有限回のリトライ後にDLQへ分離し、正常メッセージの進行を守ります。DLQ滞留数、最古Ageを監視し、修正後は安全にRedriveします。
イベントスキーマへ新フィールドを追加する。旧コンシューマーとの互換性を保つ方法はどれですか？
答え： 任意または既定値付きで追加し未知フィールドは無視させる
イベントはプロデューサーとコンシューマーを独立デプロイできるよう、前方・後方互換なスキーマEvolutionを行います。スキーマレジストリと互換性ルールで破壊的変更を検出します。
更新モデルは正規化し、検索画面は集計済みの別モデルで高速化したい。適切なパターンはどれですか？
答え： CQRSでコマンドとクエリのモデルを分けてイベントで同期する
CQRSは書込みの不変条件と読取り形状を分離できます。クエリモデル更新は通常非同期なので、遅延、再構築、冪等性、正本を明確にします。
Cache-asideで商品情報を取得する基本的な流れはどれですか？
答え： キャッシュを読みMissならDBから取得して保存し更新時は無効化する
Cache-asideではアプリケーションがキャッシュと正本DBを調整します。Miss時に遅延負荷し、更新時は通常DBコミット後にキャッシュを削除して次回再構築します。
人気キャッシュキーのTTL切れと同時に大量リクエストがDBへ到達するキャッシュスタンピード対策はどれですか？
答え： キー単位のSingle-flightとTTLジッターを組み合わせる
一つのLoaderだけが再計算し他リクエストは結果を待つSingle-flightで重複処理を抑えます。ジッターは大量キーの同時失効を分散します。
DB更新とキャッシュ削除の競合で古い値が再キャッシュされる問題を減らす設計はどれですか？
答え： コミット後にイベントで無効化しバージョン付き値や短いTTLも併用する
コミット済み変更に基づく無効化イベントとバージョン比較を使うと、遅れて到着した古い値による上書きを防ぎやすくなります。完全な同期が必要か、上限付きStalenessでよいかも決めます。
CDNで言語別・圧縮方式別のレスポンスを安全にキャッシュしたい。キャッシュキー設計はどれですか？
答え： パスとクエリに加えレスポンスが変わるヘッダーだけをキーに含める
レスポンスを変化させる入力だけをキャッシュキーへ含めます。少なすぎるとデータ混在、多すぎるとヒット率低下になるため、個人化レスポンスはキャッシュしないか安全に分離します。
キャッシュノードを一台追加した際、大半のキー再配置を避けたい。適切な分散方法はどれですか？
答え： 仮想ノード付きのコンシステントハッシュを使う
Consistentハッシュ化はハッシュRing上で近接ノードへキーを割り当て、ノード増減時の移動範囲を限定します。Virtualノードで物理ノード間の偏りも緩和します。
マルチテナントの注文DBをシャード分割する。テナント内クエリが多く、テナント間結合はほぼない。適切なシャードキーはどれですか？
答え： tenantIdを基礎にし巨大テナントは追加分割を検討する
主要アクセスパターンと同じtenantIdでCo-locationすると、多くのクエリを単一Shard内で完結できます。テナントサイズの偏りとRebalancing手順も設計します。
リードレプリカの遅延があるシステムで、在庫確保直後の確認だけは最新値が必要である。適切なルーティングはどれですか？
答え： 整合性が必要な読取りはプライマリか追随済みレプリカへ送る
読み取り要件を分類し、在庫・権限など強い整合性が必要な経路はプライマリまたは必要位置まで追随したレプリカを使います。一般画面は遅延許容でスケールできます。
5レプリカ中、書込み・読取りクォーラムを設定して重なりを保証する条件はどれですか？
答え： R + W > 5になるように設定する
NレプリカでR + W > Nなら読み取り集合と書き込み集合が少なくとも一台重なります。さらにW > N/2なら同時書き込みクォーラム同士も重なります。実装のバージョン比較も必要です。
旧リーダーが分断後も書込みを続け、新リーダーと二重更新するスプリットブレインを防ぐ仕組みはどれですか？
答え： 単調増加するフェンシングトークンで古い書込みを拒否する
リースが失効しても停止前のプロセスが遅れて動く可能性があります。下流ストレージがEpoch/フェンシングトークンを検証して古いLeaderを拒否することで安全性を守ります。
分散ロックのリースを取得してバッチを実行する。安全な実装上の注意はどれですか？
答え： リース期限と更新失敗を考慮し重要な書込みにはフェンシングを使う
分散ロックはクラッシュ回復のため期限が必要ですが、停止・遅延したオーナーが期限後に再開する危険があります。リースだけに頼らず、書込み先で古いトークンを拒否します。
HTTPサービスを複数インスタンスへ水平スケールし、任意インスタンスへルーティングしたい。適切な設計はどれですか？
答え： サービスをステートレスにしセッションは共有ストアか署名トークンで持つ
インスタンス固有状態を減らすと、ロードバランサーが任意の正常インスタンスへルーティングでき、スケールアウト・再起動・デプロイが容易になります。共有セッションストアにも可用性とTTLが必要です。
共有セッションストアが障害になると全Webインスタンスへ影響する。適切な対策はどれですか？
答え： ストアを冗長化しタイムアウトとEvictionと再認証を設計する
共有ストアは新しい集中依存になります。レプリカ・フェイルオーバー、短いタイムアウト、適切なTTLと容量監視を設け、復旧不能時は安全に再認証を求めます。
二つのリージョンで同じユーザープロファイルを同時更新できるActive-Active構成に必要な設計はどれですか？
答え： 競合検出とフィールド別マージまたは明示的な優先規則
Active-Activeではネットワーク遅延や分断により同一データへの並行書き込みが起きます。バージョンベクトル、タイムスタンプ、CRDT、業務マージなどからデータ特性に合う規則を選びます。
DNSフェイルオーバーで障害リージョンから待機リージョンへ切り替える際の注意点はどれですか？
答え： TTLとリゾルバーキャッシュで切替は遅れ両系への重複を想定する
DNS回答は再帰Resolverやクライアントにキャッシュされるため、切替中は旧・新エンドポイントへトラフィックが分かれます。TTL、ヘルスチェック、データRPO、セッション、Failbackを含めて訓練します。
一つの利用者リクエストがAPI Gateway、サービス、キュー、ワーカーを通る。エンドツーエンドで追跡する方法はどれですか？
答え： トレースコンテキストをHTTPとメッセージヘッダーで伝播する
W3Cトレースコンテキストなどを境界間で伝播し、同期・非同期処理をスパンとして関連付けます。サンプリングと個人情報Maskingを適用し、メトリクス・ログとも相関させます。
可用性SLO 99.9%を設定したサービスで、エラーバジェットを使う目的はどれですか？
答え： 許容できる信頼性不足を定量化しリリース判断の基準にするため
エラーバジェットは100%とSLOの差で、一定期間に許容する失敗量です。消費が速ければリリースを抑えて改善し、余裕があれば安全に変更を進める共通判断に使います。
平均レイテンシは100msだが一部利用者が数秒待つ。改善判断に最も有用な指標はどれですか？
答え： p95やp99のパーセンタイルをエンドポイント別に確認する
Percentileは利用者の遅いTailを可視化します。平均は大量の高速リクエストに希釈されるため、p95/p99とトラフィック量、エラー、依存先スパンを組み合わせます。
本番相当環境でサービスインスタンスを意図的に停止するChaosテストを安全に行う方法はどれですか？
答え： 仮説・影響範囲・停止条件・ロールバックを定義して小さく始める
Chaosエンジニアリングは無秩序な破壊ではなく、仮説を持つ制御された実験です。影響範囲を限定し、自動中断と観測で安全性を保ちながら弱点を発見します。
平均到着率が毎秒200件、平均処理時間が0.5秒の処理で、Littleの法則による平均同時処理数はいくつですか？
答え： 100件
Littleの法則L=λWより、200件/秒×0.5秒=100件です。平均値なのでピーク、分散、待ちキュー、余裕を別途考慮して容量を決めます。
CPU使用率は低いがキュー待ち時間が急増する非同期ワーカーをオートスケールしたい。適切な指標はどれですか？
答え： キュー深さか最古メッセージの経過時間を処理率と組み合わせる
I/O待ち中心のワーカーではCPUが飽和しなくてもバックログが増えます。キュー長さperワーカーやOldest AgeをSLOに結び付け、起動時間とScale-in時の処理中メッセージも考慮します。
複数利用者が同じ文書を更新し、古い画面からの保存で新しい変更を上書きしたくない。HTTP APIの適切な設計はどれですか？
答え： 取得時にETagを返し更新時のIf-Matchが不一致なら412を返す
ETagとIf-Matchによる条件付き更新は、クライアントが読んだバージョンと現在バージョンを比較する楽観的同時実行制御です。不一致なら再取得・マージを促します。
数分かかる動画変換要求をHTTP APIで受け付ける。適切な非同期API設計はどれですか？
答え： 202 Acceptedと操作URLを返し状態と結果をそこから取得させる
202は処理受付を表し、完了を保証しません。操作リソースへ進捗、最終結果へのリンク、失敗理由、リトライ間隔、キャンセル可否を持たせます。
商品一覧APIでオリジン障害中も短時間だけ古いキャッシュを返し、可用性を保ちたい。適切なキャッシュ方針はどれですか？
答え： 許容時間を限定したstale-if-errorを設定し鮮度要件を定義する
stale-if-errorはオリジンエラー時に期限切れレスポンスを限定時間再利用する仕組みです。許容できる古さは商品一覧と残高などデータ特性ごとに決めます。
gRPCの上流リクエストに残り500msのデッドラインがある。下流RPCを呼ぶ適切な方法はどれですか？
答え： 残り時間以下のデッドラインを伝播しキャンセルで処理を止める
エンドツーエンドデッドライン予算を下流へ伝えると、上流が結果を使えない時間まで資源を消費することを防げます。各ホップの処理余裕も差し引きます。
Read-only検索のテールレイテンシをヘッジリクエストで下げたい。安全な導入方法はどれですか？
答え： 高パーセンタイル超過時だけ一回複製し先着後に残りを取り消す
Hedgingは遅い一部リクエストを別レプリカで補いますが、追加負荷が障害を増幅し得ます。Read-onlyまたは冪等操作に限定し、遅延閾値、予算、キャンセルを設けます。
サービスが飽和しキュー遅延がSLOを超え始めた。全リクエストを受け続けて全体停止する前の適切な対策はどれですか？
答え： 同時実行数を制限し低優先度は503とRetry-Afterで早期に落とす
負荷Sheddingは処理能力を超えた作業を早期拒否し、重要処理と回復余地を守ります。Priority、アドミッションLimit、リトライ指示、監視を一緒に設計します。
API GatewayでJWT検証済みなら内部サービスは認可不要という設計の問題はどれですか？
答え： 迂回に備え各サービスも主体・権限・所有権を検証すべきである
Gatewayは外周防御として有効ですが、サービス自身が業務リソースの認可境界です。トークンの署名だけでなくIssuer、Audience、期限、スコープと対象所有権を検証します。
利用者指定URLから画像を取得する機能でSSRFを防ぐ適切な設計はどれですか？
答え： 許可ホストを検証しDNS解決後も内部IPを拒否してエグレスを制限する
SSRFはサーバーのネットワーク権限を使って内部サービスやクラウドメタデータへ接続させる攻撃です。パーサー統一、名前解決後IP検証、リダイレクト再検証、エグレス許可リストを組み合わせます。
サービス間mTLSの証明書を長期間固定した結果、漏えい時の影響が大きい。適切な運用はどれですか？
答え： ワークロードIDに基づく短命証明書を自動発行しローテーションする
短命認証情報と自動ローテーションは漏えいウィンドウを縮め、サービス単位のアイデンティティを維持します。配布失敗、期限接近、認証失敗率を監視します。
サービス検出のDNS結果をクライアントがプロセス終了までキャッシュし、新インスタンスへ切り替わらない。適切な改善はどれですか？
答え： DNS TTLを尊重して再解決し複数アドレスへ分散して接続を作り直す
検出結果には寿命があります。クライアントランタイムとコネクションプールのDNSキャッシュ挙動を確認し、TTL、再解決、接続Max Ageを設計します。
ローリング更新でPod終了時に処理中リクエストが切断される。適切なグレースフルシャットダウン設計はどれですか？
答え： 新規トラフィックから外しSIGTERM後に処理中を完了させ猶予を設ける
終了Podをロードバランサー対象から外し、アプリケーションがSIGTERMを処理して新規受付を止め、進行中処理を期限内に完了させます。長時間ジョブには再開設計も必要です。
新バージョンをカナリア5%へ配信した。自動昇格・ロールバック判断として適切なものはどれですか？
答え： 旧版とエラー率・レイテンシ・KPIを同条件で比較し閾値で判断する
カナリア分析は制御との比較で技術・業務シグナルを評価します。低トラフィックでの偶然を避ける最小サンプルと観測時間、即時ロールバック条件を事前定義します。
新しい推薦サービスへ本番リクエストをシャドー送信して比較したい。安全な方法はどれですか？
答え： シャドー側の応答は返さず書込みと外部通知を無効化する
トラフィックMirroringは新実装を本番入力で観測できますが、副作用を分離する必要があります。PIIマスク、サンプリング、追加負荷、比較ID、保持期間を設計します。
災害対策でRPO 5分、RTO 30分を定義した。意味として適切なものはどれですか？
答え： 最大約5分のデータ損失を許容し30分以内の復旧を目標にする
RPOは復旧ポイントまで遡るデータ量、RTOはサービスを復旧する時間目標です。レプリケーション頻度、バックアップ、切替自動化、依存サービス復旧順序を要件から決めます。
バックアップジョブは毎日成功しているが、災害時に復元できる確証がない。最も重要な追加対策はどれですか？
答え： 隔離環境へ定期リストアし整合性とRPO/RTOを実測する
バックアップ成功は復元成功を保証しません。定期的なリストア訓練で破損、スキーマ・バージョン差、鍵、権限、依存関係、所要時間を確認します。
イベントソーシングのプロジェクションを全イベントから再構築すると、過去イベントの外部通知まで再送された。適切な分離はどれですか？
答え： プロジェクションは副作用なしにし外部通知は別プロセスに分離する
リプレイ可能なProjectorは同じイベント列から同じ状態を作り、副作用を起こさない設計にします。通知などはアウトボックスや配信台帳で一度の意図を管理します。
APIが20個の下流サービスへファンアウトし、一つの遅延で全体のテールレイテンシが悪化する。適切な設計はどれですか？
答え： 必要な呼出しを並列化し共通デッドラインと部分結果方針を定める
ファンアウトでは各依存のTailと失敗確率が集約されます。デッドライン予算、Bulkhead、フォールバック、必要性の見直し、集約読み取りモデルでクリティカルパスを短くします。
OpenTelemetry Baggageへアクセストークンを入れて全サービスへ伝播する案の問題はどれですか？
答え： Baggageは外部ヘッダーへ伝播し得るため秘密を入れず項目を制御する
Baggageはコンテキスト情報をプロセス間で運びますが、機密性や完全性を自動提供しません。外部境界で除去し、信頼判断には認証済みClaimを使います。
分散サービス間の処理時間を各ホストの現在時刻差だけで計測すると負のレイテンシが出た。適切な方法はどれですか？
答え： プロセス内は単調クロックで測りトレースではスキューを考慮する
WallクロックはNTP補正やホスト差で前後します。単一プロセスの期間にはMonotonicクロックを使い、サービス間はトレースID、スパン親、イベント順序で因果を追います。
同じ重い商品検索が同時に多数到着し、全てが同じ下流クエリを実行している。適切なリクエスト集約はどれですか？
答え： 正規化した同一キーの進行中処理を共有し結果を各呼出しへ配る
Singleflight型のCoalescingは同じキーの同時Missを一つの作業へまとめます。認可コンテキストをキーへ含め、短い共有範囲、キャンセル、エラーキャッシュ方針を設計します。
認証後の画面に機密データを返すAPIで、準拠したHTTPキャッシュに応答を保存させたくありません。Cache-Controlの指定として適切なのはどれですか？
答え： no-storeを指定し、応答の保存を禁止する
no-storeは保存禁止の指示です。no-cacheは保存自体を禁止せず、再利用前の検証を要求します。既に保存されたデータの完全削除や、アプリ独自の保存まで保証する仕組みではありません。
クライアントが保存済み本文とETagを持ち、GETにIf-None-Matchを付けたところ304が返りました。この応答の扱いとして適切なのはどれですか？
答え： 対応する保存済み本文を使い、返されたメタデータを反映する
304は条件付きGETの対象が変更されていないことを示し、本文を含みません。対応する保存済み表現を再利用し、キャッシュメタデータを更新します。
同一オリジン内で、POSTを一時的な別URLへ自動リダイレクトさせます。追従時にメソッドと本文を維持させたい場合、適切なステータスはどれですか？
答え： 307を返し、POSTのまま追従させる
307は一時的なリダイレクトで、追従時にメソッドを変更させません。302ではPOSTがGETへ変わる場合があります。
安全に再試行できるGETが429と Retry-After: 30 を返しました。クライアントの残り待機予算は5秒です。適切な対応はどれですか？
答え： 同期再試行を打ち切り、後で試せる結果を返す
この値は30秒の待機を示し、5秒の残り予算には収まりません。待機指示を無視して連打せず、呼び出し元へ失敗を返すか、別途合意された非同期再実行へ委ねます。
Webhookの署名方式は受信した本文の生バイト列を対象にしています。JSON解析後に再シリアライズした本文で検証すると、正規の通知も失敗しました。適切な修正はどれですか？
答え： 変換前の本文を保持し、送信元の方式で署名を検証する
JSONとして同じ意味でも、空白やキー順の変更でバイト列は変わります。仕様が生本文への署名なら、変換前の本文と指定ヘッダーを使って検証し、成功後に業務処理へ渡します。
Webhook本文とタイムスタンプをまとめて署名する方式です。過去の正規通知をそのまま再送されても、古い通知として拒否したい場合、署名検証に何を加えますか？
答え： 署名対象の時刻を確認し、許容時間を超えた通知を拒否する
署名は改ざんを検知しても、正規メッセージの再送だけでは壊れません。署名対象の時刻と信頼できる現在時刻を比較します。許容時間内の重複は別にイベントIDなどで排除し、正規の再配信も考慮します。
ページング用カーソルにテナントIDと続き位置を入れ、改ざん防止の署名を付けました。別テナントが入手した有効なカーソルを送ってきた場合、必要な処理はどれですか？
答え： 認証主体の権限と対象テナントを照合し、越境を拒否する
カーソルの署名は発行後の改ざんを防ぎますが、その保持者に閲覧権限がある証明ではありません。各ページ取得で認証・認可を行い、カーソルの対象と検索条件も整合させます。
JSON Merge Patchで {"name":"旧名","phone":"123"} に {"name":"新名","phone":null} を適用します。RFC 7396に従う結果はどれですか？
答え： nameが変わり、phoneというメンバーは削除される
JSON Merge Patchではオブジェクト内のnullは、そのメンバーの削除を表します。省略されたメンバーはそのままです。null自体を値として保存したいAPIでは、この方式の制約を踏まえて別の更新表現を検討します。
DELETEが成功し、APIが204 No Contentを返します。クライアントがすべての2xx応答へJSON解析を行うため失敗しています。適切な修正はどれですか？
答え： 204では本文解析を省き、成功として処理する
204は成功を示し、本文を含みません。ステータスに応じて解析を分岐します。JSON本文が必要なら、API側の応答契約を200などに変える方法を検討します。
A→B→Cの同期呼び出しで、AはBを最大3回、Bは各要求についてCを最大3回呼びます。Cが毎回失敗し、全試行を行える時間がある場合、Aへの1要求からCへの最大呼び出し数と改善方針はどれですか？
答え： 最大9回なので、再試行の担当層と総予算を整理する
各B呼び出しでCを3回呼ぶため、最大は3×3=9回です。多層の再試行は負荷を掛け算で増やします。再試行する層を明確にし、残り時間・試行数・冪等性を考慮して全体を制限します。