観測 → 仮説 → 検証 → 判断を、自分の経験から説明する。
次の焦点 CPU・I/O・接続プールの待ちを、観測値から切り分ける。
性能の振り返り → DNS・通信の振り返り → 経験：DB遅延・DNS調査 ↗ 記録と再確認の問い 2026-09-15 [2026-09-15-network-dns-mtu-01] 次回、pcapとFlow Logを使って、問い合わせ/応答サイズ、TC、UDP/TCP、ICMPv6 Packet Too Big、fragmentation、capture位置をどの区間で観測するかを具体化する。 根拠: Issue #19「次回」の本人希望と未確認事項。実pcap・面接説明は未実施、今回の仕組み説明にはヒントあり。 2026-09-15 [2026-09-15-network-dns-mtu-01] 元ケースで『大きい成功例にTCP/53があった』『失敗例でUDP復路欠落』という観測から、どの追加観測ならGRE/PMTU仮説を支持・棄却できるかを整理する。 根拠: Issue #19「次回」の本人希望と未確認事項。実pcap・面接説明は未実施、今回の仕組み説明にはヒントあり。 2026-09-15 [2026-09-15-network-dns-mtu-01] GRE outer IPv4のDF、outer fragmentation、inner IPv6 PMTUD、tunnel MTUの関係を、pcap上でどのheader/flagを見るかまで確認する。 根拠: Issue #19「次回」の本人希望と未確認事項。実pcap・面接説明は未実施、今回の仕組み説明にはヒントあり。 2026-09-15 [2026-09-15-network-dns-mtu-01] 他者事例から学んだこととして、HTTP/HTTPSを支えるネットワーク、クラウド接続、可用性、観測に基づく仮説修正の観点で短い面接説明を本人が試す。実務経験としては扱わない。 根拠: Issue #19「次回」の本人希望と未確認事項。実pcap・面接説明は未実施、今回の仕組み説明にはヒントあり。 2026-09-15 (2026-09-15-systems-performance-01): run queueとCPU utilization/saturationの関係を、CPUが空いているのにrun queueが長い場合に何を疑うかまで再確認する。 2026-09-15 (2026-09-15-systems-performance-01): connection poolのmax size、active、idle、wait timeを使って、pool待ちとdownstream latencyをどう切り分けるかを別条件で再確認する。 2026-09-15 (2026-09-15-systems-performance-01): backpressureを、同期APIではbounded concurrency/queue/timeout/429・503、非同期処理ではqueue/consumer制御としてどう設計するかを次回確認する。 2026-09-15 (2026-09-15-systems-performance-01): Issue #21の追記（2026-09-16）で希望: 性能劣化の最初の観測を、症状・影響区間・CPU/core/runnable・memory/I/O・app内待ちに対応するLinux/AWSコマンドと理由で短く説明する。追加テストは未実施。 BFF・ウォレットでの判断から、負荷・整合性・再送を考える。
次の焦点 再送・重複・途中失敗への対処を、保証できる範囲まで説明する。
APIの冪等性 → キュー → 負荷と容量 → 経験：BFF移行・ウォレット運用 ↗ 記録と再確認の問い 2026-09-08 / 2026-09-08-architecture-api-idempotency-01: 次回はヒントなしで、注文作成APIの契約としてidempotency keyの生成主体・scope・payload mismatch時の扱い・DB一意制約・再送時のresponse再現まで一連で説明する。 2026-09-08 / 2026-09-08-architecture-api-idempotency-01: 外部決済を含む場合、order_idとpayment_attempt_idを分け、外部決済サービス側のidempotency key、状態照会/reconciliation、ローカルstate machineをどう組み合わせるかを再出題する。 2026-09-10 [2026-09-10-int-burst-01-01] provider keyの提案は条件提示後・解法ヒントなしで再確認。key/照会のあり・なし別にretry、照合、手動復旧、at-most-onceを説明し、ローカルclaimとの保証境界を再確認する。外部key非対応の限界は今回独力未解決。 2026-09-08 / 2026-09-08-architecture-api-idempotency-01: paginationは `ORDER BY created_at DESC, order_id DESC` と複合cursorを前提に、次ページWHERE条件をヒントなしで説明する。offsetとの差をinsert/delete両方で説明する。 2026-09-08 (2026-09-08-architecture-queues-01): 次回、Transactional Outboxを名称なしで再出題し、orders更新とoutbox event作成を同一transactionに置く理由、およびoutbox→queue間では重複を許容する理由を自発的に説明できるか確認する。 根拠: 同sessionの回答・説明後の理解。自力での再確認は未実施。 2026-09-10 [2026-09-10-int-burst-01-01] 受付のDB正本への変更は観点ヒント後。DB/queue間の失敗条件に未投入再送・重複許容を説明したが、受付commitと照会契約は次回独力再確認。 2026-09-08 (2026-09-08-architecture-queues-01): at-least-once / at-most-once / exactly-once side effectの違いを、queue deliveryと実際の外部副作用を分けて再度説明する。特に『exactly-once delivery』という語に引きずられず、consumer冪等性との組み合わせを説明できるか確認する。 根拠: 同sessionの回答・説明後の理解。自力での再確認は未実施。 2026-09-10 [2026-09-10-int-burst-01-01] 外部key非対応で自前exactly-once案が未解決。at-most-once選択は解法説明後。 2026-09-08 (2026-09-08-architecture-queues-01): idempotency keyの実装をさらに深掘りする。ローカルDB内でUNIQUE制約+transactionにより実現できる範囲と、外部副作用をまたぐときに下流のidempotency / transaction ID / status query / reconciliationが必要になる理由を再出題する。 根拠: 同sessionの回答・説明後の理解。自力での再確認は未実施。 2026-09-08 (2026-09-08-architecture-queues-01): source of truth / authoritative ledgerとreconciliationを、銀行・決済以外の例でも説明できるか確認する。 根拠: 同sessionの回答・説明後の理解。自力での再確認は未実施。 2026-09-08 (2026-09-08-architecture-queues-01): SQS等を題材にvisibility timeout、ack/delete、receive count、retry、DLQ、redriveのライフサイクルを図なしでも説明できる状態を目指す。 根拠: 同sessionの回答・説明後の理解。自力での再確認は未実施。 2026-09-10 [2026-09-10-int-burst-01-01] 原稿Q3は未出題。今回の不足認定ではなく未実施の再確認として残す。 2026-09-08 (2026-09-08-architecture-queues-01): queue運用ではqueue depthだけでなくoldest message age、enqueue/consume rate、retry count、error rate、DLQ depth/ageをどう組み合わせて見るかをproduction scenarioで再出題する。 根拠: 同sessionの回答・説明後の理解。自力での再確認は未実施。 2026-09-08 (2026-09-08-architecture-queues-01): DLQ大量復旧時に、redrive rate・consumer concurrency・下流rate limit・新規トラフィックの公平性をどう調整するか、より深いcapacity planning問題へ進む。 根拠: 同sessionの回答・説明後の理解。自力での再確認は未実施。 2026-09-08 / 2026-09-08-architecture-scaling-01 / DB connection pool問題を別条件で再出題し、connection総数だけでなくconnection hold time、query/transaction/lock wait、pool waitを自発的に切り分けられるか確認する。 根拠・ヒントは本sessionの該当観察を参照。 2026-09-08 / 2026-09-08-architecture-scaling-01 / arrival rate・processing rate・burst duration・backlog・deadlineから、許容arrival rateやdrain timeを式で自力計算する問題を再出題する。今回、drain timeを一度見落としたため。 根拠・ヒントは本sessionの該当観察を参照。 SLOの起点とburst後の通常流入をまず確認する。 2026-09-10 [2026-09-10-int-burst-01-01] 原稿Q2は未出題。backlog、burst集団完了、全queue解消を別sessionで独力確認する（今回の不足認定ではない）。 2026-09-08 / 2026-09-08-architecture-scaling-01 / rate limit / quota / priority / tenant isolationを同じnoisy-neighbor scenarioで比較し、公平性・SLO・UX・system protectionのtrade-offを理由付きで選べるか確認する。 根拠・ヒントは本sessionの該当観察を参照。 quota質問への説明はあり。ただしAWSではrateもquotaに含むため、AI説明の単純化を訂正して再確認する。 2026-09-08 / 2026-09-08-architecture-scaling-01 / 負荷試験でcapacityを固定してloadを増やし、throughputの飽和、tail latency、error、queue/DB/network等からknee pointを判定する設計をヒントなしで再説明する。 根拠・ヒントは本sessionの該当観察を参照。 経験の少ない領域。APIの正しさと性能に必要なところから。
次の焦点 分離レベルとロックを使い分け、実際の実行計画を読む。
トランザクション → 実行計画 → インデックス → 経験：APIの更新・検索を題材にする ↗ 記録と再確認の問い 2026-09-14 (2026-09-14-database-query-plans-02): 実際のPostgreSQL EXPLAIN (ANALYZE, BUFFERS)出力を木構造の下側から読み、各nodeのactual time、rows、loops、Buffersから支配的コストを自力で特定する。 2026-09-14 (2026-09-14-database-query-plans-02): Nested LoopとHash Joinについて、build/probe側、外側行数、selectivity、index lookup回数、memory/spillを条件にして、説明なしでjoin strategyを選び直す。 2026-09-14 (2026-09-14-database-query-plans-02): 推定誤差を、統計の古さ、単一列skew、複数列相関、parameterized Generic Planに切り分け、対応策を対応付ける短い再テストを行う。 2026-09-14 (2026-09-14-database-query-plans-02): Sort Method、Memory、Disk、Buffers、Rows Removed by Filterを含むplanを読み、行数見積もりが正しいのに遅いケースを診断する。 2026-09-17 (2026-09-17-database-transactions-01): READ COMMITTED / REPEATABLE READ / SERIALIZABLEを、同じ具体シナリオで『何が見えるか』『いつ待つか』『いつabortするか』『retry要否』まで再確認する。今回REPEATABLE READとSERIALIZABLEは説明を受けながら理解した部分が多い。 2026-09-17 (2026-09-17-database-transactions-01): FOR UPDATE / NOWAIT / SKIP LOCKED / optimistic locking / 条件付きUPDATEを、競合率・latency・connection pool・retryコストの観点で使い分ける練習を別条件で再確認する。 2026-09-17 (2026-09-17-database-transactions-01): write skewとSERIALIZABLEのread/write dependency検出を、別の複数行不変条件の例で自力説明できるか確認する。 2026-09-17 (2026-09-17-database-transactions-01): 高競合時に条件付きUPDATEを第一候補にできるケースと、明示ロック・queueing・data model変更が必要なケースの境界を整理する。 2026-09-17 (2026-09-17-database-transactions-01): deadlock（複数行を異なる順序でロックするケース）は終了時に未出題のまま残したため、次回扱う候補とする。 2026-09-17 (2026-09-17-database-transactions-01): 楽観ロックのUPDATEも未commitの競合更新を待ち得る。commit済みversion不一致の0件と、競合writerの待機を別条件で確認する（Issueの待機不要という説明は一般化しない）。 互換性検証・共通化・段階移行を、今の知識で説明し直す。
次の焦点 何を検証でき、何を見逃したか。継続・中止の判断を説明する。
テスト → デプロイ → 認証・認可 → 経験：開発手順・互換性検証・CMS ↗ 記録と再確認の問い 2026-09-10 [2026-09-10-software-testing-01] unit / integration / E2E の用語を別の小例で再度独力分類し、名称だけでなく『何を本物にして何を偽物にするか』『何を保証するか』まで説明する。 根拠: 分類軸の説明後に実MySQLとmock Serviceを分類。独力の別例は未確認。 2026-09-10 [2026-09-10-software-testing-01] DI/interfaceを導入する判断を、testabilityの利益と抽象化コストのtrade-offから別例で再確認する。 根拠: 初回は「常に良い」、説明後にClockの利益を回答。 2026-09-10 [2026-09-10-software-testing-01] time / timezone / DSTの境界値テストを、仕様上必要なケースと過剰なケースに分けて再確認する。 根拠: 境界説明後に22:00直前/境界を選択、ZoneId整理後の回答。DSTは存在を問う追質問あり。 2026-09-10 [2026-09-10-software-testing-01] 今回未回答で終了したCIテスト戦略を続ける。unit 500 / integration 80 / E2E 20という演習条件で、毎PR・main merge後・夜間の振り分けを、検知速度・flakiness・実行コスト・failure localizationから判断する。 根拠: CIの問いを提示後に終了。未回答・解法ヒントなし。