Orivel Orivel
メニューを開く

お題・ディスカッション一覧

公開されている最新のお題やディスカッションをまとめて確認できます。

比較ジャンル

モデル一覧

システム設計

Anthropic Claude Opus 4.7 VS Google Gemini 2.5 Flash

スケーラブルなコンサートチケット予約システムの設計

オンラインのコンサートチケット販売プラットフォームのためのシステムを設計してください。ユーザーはイベントを閲覧し、座席の空き状況を確認し、特定の座席を10分間予約し、外部の決済プロバイダを通じて支払いを行い、デジタルチケットを受け取ることができます。プラットフォームは1つのクラウドリージョン内で複数のアベイラビリティーゾーンにまたがって稼働します。 明示的制約: 登録ユーザー数は3百万、日間アクティブユーザーは50万、主要な販売開始イベントでは同時接続ユーザーが15万に達する可能性がある、ピーク負荷は座席予約試行が毎秒8,000件、決済試行が毎秒2,000件、各イベントの座席数は最大60,000席、同じ座席が二重に販売されてはならない、未支払いの座席予約は10分で期限切れになる、閲覧および座席マップ読み取りのp95レイテンシは300ms未満、予約確定のp95レイテンシは決済プロバイダ時間を除いて800ms未満、販売開始ウィンドウ中の可用性目標は99.95%、復旧ポイント目標(RPO)は1分未満、復旧時間目標(RTO)は15分未満、決済プロバイダのコールバックはat-least-onceで到着順が入れ替わる可能性があり、最大5分の遅延が発生する可能性がある。 設計プランを提示してください。主なサービスとデータストア、コアAPI、座席と予約のデータモデル、閲覧・予約・支払い・予約失効のリクエストフロー、トラフィックスパイクに対するスケーリング戦略、信頼性および災害復旧アプローチ、過剰販売(overselling)を防ぐための整合性選択、監視とアラート、ならびに検討した主要なトレードオフや代替案を含めてください。合理的な仮定があれば明記してください。

174
2026/05/19 09:49

分析

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

成長するSaaSスタートアップのためのデータベース選定

あなたは、中堅企業向けにプロジェクト管理ソフトを提供する創業2年目のB2B SaaSスタートアップのCTOに助言を行っています。現在の構成は単一のPostgreSQLインスタンスで、現在以下のような問題が発生しています:ダッシュボード上の読み取りクエリがピーク時間帯で3~8秒かかる、データベース容量は800 GBで月約40 GBずつ増加している、チームは今後12か月でユーザー数が3倍になると予想している。エンジニアリングチームは開発者9名で、そのうちデータベース管理の経験が豊富なのは1人だけ。予算は制約があるが極端に厳しいわけではない。 CTOが検討している4つの選択肢は次のとおりです: 1. 既存のPostgreSQLインスタンスを垂直スケールし、リードレプリカを追加する。 2. マネージドの分散SQLデータベース(例:CockroachDBやSpannerに類似したサービス)へ移行する。 3. ワークロードを分割する:トランザクションデータはPostgreSQLのままにし、ダッシュボード向けに別の分析ストア(例:ClickHouseやBigQuery)を導入する。 4. NoSQLドキュメントデータベース(例:MongoDBやDynamoDB)へ移行する。 概ね500〜800語の分析を書いてください。分析には以下を含めてください: - 4つの選択肢それぞれを、このスタートアップ固有の制約(パフォーマンスボトルネックの場所、チームの専門性、成長予測、予算)に照らして評価する。 - 各選択肢の主要なトレードオフとリスクを特定する。 - 明確で正当化された推奨(単一の選択肢または段階的な組み合わせを推奨してよい)に到達する。 - 推奨を確定する前に検証したい証拠や測定項目を具体的に示す。 具体的にしてください:与えられた数値に言及し、このシナリオを無視した一般的なデータベース助言は避けてください。

210
2026/05/16 09:38

プログラミング

OpenAI GPT-5.5 VS Google Gemini 2.5 Flash

スライディングウィンドウとバースト許容を備えたレートリミッタ

スライディングウィンドウ会計とバースト許容をサポートする、スレッドセーフなレートリミッタを選択した言語(Python, Go, Java, TypeScript, または Rust)のいずれかで設計・実装してください。要件は次のとおりです。 1. **API surface**: 少なくとも次の操作を公開してください: - `allow(client_id: str, cost: int = 1) -> bool` — 現時点でリクエストが許可されるかどうかを返します。 - `retry_after(client_id: str) -> float` — 少なくとも1単位の容量が利用可能になるまでの秒数を返します(現在許可されている場合は0)。 - クライアントごとの設定を受け取るコンストラクタ: `rate`(単位/秒)、`burst`(蓄えられる最大単位)、およびスライディングウィンドウ会計のためのオプションである `window_seconds`。 2. **Algorithm**: **トークンバケット**(バースト許容のため)と **スライディングウィンドウ(ログまたはカウンタ)**(`window_seconds` 内で許可される総リクエストを上限するため。純粋なトークンバケットではリフィル後に持続的な乱用を許してしまう)を組み合わせたハイブリッドを実装してください。リクエストは両方のチェックが通った場合にのみ許可されます。スライディングウィンドウのデータ構造選択(正確なログ vs. 重み付き二窓近似)について正当化し、メモリ/精度のトレードオフを短いコメントブロックまたは付随するノートで議論してください。 3. **Concurrency**: リミッタは同一および異なる `client_id` に対して多くのスレッド/ゴルーチンから同時に呼ばれます。単一のグローバルロックがボトルネックにならないようにしてください(例:クライアント毎のロック、ロックストライピングなど)。同時実行の `allow` 呼び出しの下であなたのアプローチが正しい理由(トークンの二重消費が起きない、更新の取りこぼしがない)を文書化してください。 4. **Time source**: テストが決定論的になるようにクロックを注入可能にしてください。デフォルトではモノトニッククロックを使用してください。 5. **Edge cases to handle explicitly**: - `cost` が `burst` より大きい場合(拒否すること、永遠にブロックしないこと)。 - クロックの巻き戻しや長時間の一時停止(例:サスペンドされたVM):クラッシュさせずにクランプ(調整)し、無制限のトークンを付与しないこと。 - 新規クライアントの最初のリクエスト(遅延初期化)。 - ステールなクライアントのクリーンアップ(クライアントが停止してもメモリが無制限に成長しないこと)。 - 小数トークン/サブミリ秒の時間処理。 6. **Tests**: 注入可能なクロックを使用して、少なくとも6つの単体テストを提供してください。対象は:基本的な許可/拒否、バーストの枯渇とリフィル、バケットのリフィルとは独立したスライディングウィンドウ上限、`cost > burst`、1クライアントへの同時競合(決定論的特性:ある期間 T 秒内に許可される合計 ≤ rate*T + burst)、およびステールクライアントの除去を含みます。 7. **Complexity**: `allow` の償却時間計算量とクライアントあたりのメモリ計算量を明示してください。 Deliver: 完全な実行可能コード(単一ファイルで可、ただしファイルを分ける場合は明確にラベル付けしてください)、テスト、および設計ノート(最大約250語)を提出してください。

190
2026/05/12 09:45

41〜60件を表示 / 全537件

関連リンク

X f L