Orivel Orivel
メニューを開く

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

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

比較ジャンル

モデル一覧

システム設計

Google Gemini 2.5 Flash VS Anthropic Claude Sonnet 4.6

グローバルなURL短縮サービスを設計する

Bitlyのような公開URL短縮サービスを設計してください。ユーザーは長いURLを送信して短いエイリアスを受け取れるものとし、短縮リンクにアクセスした際には元のURLへ迅速にリダイレクトされる必要があります。システムは、カスタムエイリアス、任意の有効期限、基本的なクリック分析、悪意のあるリンクに対する不正利用対策をサポートしなければなりません。 要件と制約: - 機能要件: - 長いURLに対する短縮URLを作成する。 - 短縮URLを元のURLへリダイレクトする。 - 利用可能な場合はカスタムエイリアスをサポートする。 - リンクごとに任意の有効期限をサポートする。 - 分析のためにクリックイベントを記録する。 - ユーザーがリンクを手動で無効化できるようにする。 - スケール前提: - 毎月1億2,000万件の新しい短縮URL。 - 1日あたり15億件のリダイレクト。 - リダイレクトトラフィックはグローバルに分散しており、読み取り負荷が高い。 - 分析データは15分以内にクエリ可能であるべき。 - 性能目標: - 大半のリージョンで、リダイレクトのp95レイテンシを80ms未満。 - 短縮リンク作成のp95を300ms未満。 - リダイレクトに対して99.99%の可用性。 - データと保持期間: - リンクは、有効期限切れまたは無効化されない限り、無期限に存続しうる。 - 生のクリックイベントは90日間保持してよく、集計済み分析は2年間保持する。 - 運用上の制約: - 一般的なクラウドインフラを使用すること。1つの特殊なマネージド製品ですべてが解決すると仮定してはならない。 - 予算は重要である。あらゆるレプリケーション、キャッシュ、ストレージの選択を正当化すること。 - 短縮コードはコンパクトで、大規模時にある程度推測しにくいものであるべきだが、完全な秘匿性は不要である。 回答では、以下を提供してください: 1. 主要コンポーネントとデータフローを含む高レベルアーキテクチャ。 2. リンクメタデータ、リダイレクト経路、分析イベントに対するストレージ選択と、その根拠。 3. 短縮コード生成戦略。衝突回避方法とカスタムエイリアスの扱いを含む。 4. キャッシュ、パーティショニング/シャーディング、マルチリージョンの考慮を含む、グローバルトラフィック向けのスケーリング計画。 5. 障害、ホットキー、災害復旧、性能劣化時の動作を扱う信頼性計画。 6. 主要APIとコアデータモデル。 7. 不正利用対策およびセキュリティ上の考慮事項。 8. 主にどのようなトレードオフを行ったか、その理由。

55
2026/03/20 11:03

システム設計

Google Gemini 2.5 Pro VS Anthropic Claude Sonnet 4.6

グローバルなURL短縮サービスの設計

Bitlyに類似した公開URL短縮サービスを設計してください。ユーザーは長いURLを送信して短いエイリアスを受け取り、誰でも短縮リンクを使って元のURLへリダイレクトできるようにします。 あなたの設計は次の要件と制約を満たす必要があります: 機能要件: - 任意の有効なURLに対して短縮リンクを作成すること。 - 低レイテンシで短縮リンクをリダイレクトすること。 - 利用可能な場合に任意のカスタムエイリアスをサポートすること。 - リンクごとの基本的なクリック解析を提供すること:総クリック数、過去24時間のクリック数、およびクリック数上位5か国。 - リンクの有効期限を設定可能にすること。 スケール想定: - 1日あたり1億2,000万件の新規短縮リンク作成。 - 1日あたり80億件のリダイレクト要求。 - 読み取り中心のワークロードで強いトラフィックスキュー:リンクのごく一部が非常に高いトラフィックを受ける。 - ユーザーは北米、ヨーロッパ、アジアにまたがるグローバルな分布。 制約: - リダイレクトに対して99.99%の可用性目標。 - 主要地域のユーザーに対するP95リダイレクトレイテンシを80 ms未満。 - 新規作成されたリンクはグローバルに2秒以内に利用可能になること。 - 解析は最終的整合性で構わないが、リダイレクトは正確でなければならない。 - 予算は重要:どこにより強い整合性やマルチリージョン複製に費用をかけるか、どこを避けるかを正当化すること。 - サードパーティのマネージド解析製品は利用しないものとし、コアシステムを設計すること。 以下を提供してください: - 主要コンポーネントとデータフローを含む高レベルのアーキテクチャ。 - リンクマッピング、解析イベント、およびホットリンクのキャッシュに関するストレージの選択。 - 衝突処理やカスタムエイリアスのチェックを含むID生成またはエイリアス戦略。 - create-link、redirect、and analytics retrieval のAPI設計。 - ホットキー、キャッシュ、パーティショニング、およびマルチリージョントラフィックに対するスケーリング手法。 - フェイルオーバー、データ複製、バックアップ、および劣化時の振る舞いを含む信頼性戦略。 - 主要なトレードオフと、検討して却下した少なくとも2つの代替設計選択肢。

64
2026/03/19 04:33

システム設計

OpenAI GPT-5.2 VS Anthropic Claude Sonnet 4.6

リアルタイムのライドシェア通知システムの設計

あなたは、人気のライドシェアアプリケーション向け通知システムのハイレベルなアーキテクチャを設計する任務を負っています。システムは、1,000,000人のデイリーアクティブユーザー(DAU)と、1日あたり平均500,000件の乗車を処理でき、ラッシュアワー時にはピークが発生することに対応できなければなりません。 システムは以下の種類の通知を配信する必要があります: 1. ドライバーが割り当てられた。 2. ドライバーがまもなく到着する(例: 2分以内)。 3. 乗車が完了し領収書が利用可能になった。 4. 特定の地理的エリアにいるユーザーを対象としたプロモーションメッセージ。 あなたの設計提案は、以下の点に対処する必要があります: - コンポーネントとその相互作用のハイレベルなアーキテクチャの説明。 - 主要な技術選択(例: メッセージキューイング、データベース、プッシュ通知サービス)とそれらの選択理由。 - 低レイテンシ(配信時間2秒未満)と高信頼性(少なくとも1回配信)を確保するための戦略。 - ピーク時の負荷を処理するためにシステムをどのようにスケールさせるか。 - 設計で行った主要なトレードオフの議論(例: コスト対性能、一貫性対可用性)。

69
2026/03/18 20:31

システム設計

Anthropic Claude Sonnet 4.6 VS OpenAI GPT-5 mini

スケーラブルなリアルタイム通知システムの設計

あなたは、急速に成長しているソーシャルメディアプラットフォームのためにリアルタイム通知システムを設計する責務を負うシニアソフトウェアエンジニアです。システムは、現在オンラインのユーザーに対して(例:'新しいいいね'、'新しいコメント'、'友達リクエスト')通知を配信できなければなりません。 **システム要件:** * **機能:** 1. ユーザーは異なる通知トピック(例:自分の投稿の更新、特定の友人からの更新)を購読できること。 2. イベント公開サービスは特定のトピックまたはユーザーにメッセージを送信できること。 3. 購読していてオンラインのユーザーは関連する通知をリアルタイムで受信すること。 * **非機能(制約):** 1. **スケーラビリティ:** システムは100万の同時オンラインユーザーと、秒間1万件の通知のピーク負荷をサポートすること。 2. **レイテンシ:** 通知の99%はイベントが公開されてから200ミリ秒以内にユーザーのデバイスに配信されること。 3. **信頼性:** システムは通知の最低1回配信(at-least-once delivery)を保証すること。 4. **可用性:** システムは99.95%の稼働率を持つこと。 **あなたのタスク:** 高レベルなシステム設計を提示してください。あなたの回答は以下を網羅するべきです: 1. 全体アーキテクチャ(APIゲートウェイ、通知サービス、メッセージキュー、データベース、クライアント接続管理などの主要コンポーネントを含む)。 2. 主要コンポーネントのための技術選択とその理由(例:WebSockets vs. Long Polling、Kafka vs. RabbitMQ、NoSQL vs. SQL)。 3. 設計がスケーラビリティ、レイテンシ、信頼性、可用性の要件にどのように対処しているか。 4. 設計であなたが行った可能性のあるトレードオフに関する議論。

87
2026/03/16 05:05

関連リンク

X f L