Cursor エンジニアが解説：Git ホスティング 20 年の難問 — Continuity アーキテクチャ詳解
GitのDAGとpackfile、GitHub Spokes、そしてS3 WALを唯一の信頼できる情報源とするContinuityまで。大規模Gitホスティングの難しさと、Cursorの解決策を詳しく解説します。
- Vicent Martí氏はlibgit2やGitHubのGitインフラに長年携わってきました。本記事では大規模Gitホスティングのアーキテクチャの変遷を振り返りつつ、CursorのOriginプラットフォームの技術基盤を説明します。
- GitのDAG、packfile、強い整合性への要求により、オブジェクトデータベース、ネットワークファイルシステム、固定レプリカ方式のそれぞれが規模拡大の壁に直面します。
- ContinuityはS3 WALを唯一の信頼できる情報源とし、ローカルGitをホットキャッシュとして使うことで、サービスレプリカをトラフィックに応じて0からスケールさせます。100、120、300という数値はCursorの自己報告であり、完全なテスト条件と再現可能なデータは公開されていません。
この記事はCursor公式ブログからのもので、著者はVicent Martí氏です。エディタの機能やモデルの能力ではなく、より根本的な問題を扱っています。大規模なGitホスティングがなぜ非常に困難なのか、そしてCursorが自社のコードホスティングプラットフォームのために、なぜGitストレージシステムを一から作り直すのか。
Vicent Martí氏は現在Cursorでシステム関連の仕事をしており、以前はPlanetScaleとGitHubに在籍していました。2010年にはGoogle Summer of Codeでlibgit2に参加。その後、GitHubのシステムチームでclone、fetch、packfile、大規模リポジトリのパフォーマンスに長く携わりました。2015年には、GitHubがGitのネットワーク操作における平均CPU時間を90%以上削減した方法を記録し、その最適化をアップストリームのGitに還元しました。
この経歴は重要です。これはAI企業によるGitアーキテクチャの二次的な整理ではなく、長年Gitの低レイヤーとホスティングシステムに携わってきたエンジニアが、Cursorの新プラットフォームについて書いたファーストパーティの技術解説です。
2026年6月、CursorはCompileカンファレンスで新しいGitプラットフォーム「Origin」を発表しました。その2ヶ月後、この記事で初めてOriginの基盤となるストレージシステム Continuity が体系的に解説されました。そのため、この記事には2つの役割があります。過去20年のGitホスティングで経験してきた問題を振り返ること、そしてCursorが「ユーザーのコード作成を支援するツール」から「ユーザーのソフトウェアの歴史を預かるインフラ」へと向かう能力を持つことを示すことです。
この記事全体の核心は、まず次の一言に集約できます。
Continuityは、ローカルのNVMe上にネイティブなGitリポジトリを保持しますが、S3上の先行書き込みログ（WAL）を唯一の信頼できる情報源とします。これにより、ディスク上のコピーは、注意深く管理しなければならない重要なデータから、トラフィックに応じて増やしたり、破棄したり、再構築したりできるホットキャッシュへと変わります。
1. 核心的な課題：なぜ大規模Gitホスティングは悪夢なのか
GitはもともとLinuxカーネルのような、高度に非中央集権的でオフラインでの作業を可能にするプロジェクト向けに設計されました。すべての開発者が完全なリポジトリを持ち、サーバー上のリポジトリと開発者のコンピュータ上のリポジトリは、基本的に同じ実装を使用します。
このため、小規模なGitサービスは簡単に構築できます。ディスク上のリポジトリの前にHTTPエントリポイントを置くだけで動作します。しかし、GitHub、GitLab、またはエンタープライズレベルのコードホスティングの規模になると、「サーバーとノートパソコンが完全に同じ」という設計は、3つのレベルの問題を引き起こします。
1. Gitの基盤データはグラフ構造
Gitのcommit、tree、blobなどのオブジェクトは、SHAを介して相互に参照し、有向非巡回グラフ（DAG）を構成します。
あるcommitを読み取る場合、システムはまずそのcommitを取得して、そのルートツリーと親コミットがどこにあるかを知る必要があります。ツリーを取得して初めて、次のレベルのファイルとサブディレクトリのアドレスがわかります。次のステップで必要なキーは、前のステップの結果の中に隠されているのです。
そのため、各Gitオブジェクトを分解して分散キーバリューストアに保存するのは、「コンテンツアドレス指定」の直感に合っているように見えますが、実際には、一度のローカル走査が膨大な数のシリアルなネットワークラウンドトリップになってしまいます。次のステップで何にアクセスするかがまだわからないため、多くのリクエストを事前に並行処理することはできません。
2. Packfileが物理的なジャンプをさらに追加する
Gitはすべてのオブジェクトを完全な形で保存するわけではありません。スペースを節約するために、多数のオブジェクトをpackfileに圧縮し、あるオブジェクトが別のベースオブジェクトに対してどれだけ異なるかをデルタで記録します。そして、そのベース自体がさらに別のデルタに依存していることもあります。
その結果、論理オブジェクトを読み取る際、GitはDAGに沿ってポインタを探すだけでなく、数GBに及ぶpackfile内の複数の物理的な場所をまたいで移動して、オブジェクトを復元する必要がある場合があります。ローカルNVMeはこれらのランダムリードを非常に低いレイテンシに抑えられますが、ネットワークファイルシステムをまたぐと、ジャンプのたびにネットワークコストを支払うことになります。
操作方法：自動再生を一時停止するか、「前へ / 次へ」でリモート読み取りを1段階ずつ確認します。
次のオブジェクト群のアドレスはまだ分かりません。
インデックスがGitに示すのは、packfile内でのオブジェクトの位置だけです。
3. Gitは安易な「結果整合性」を許容できない
多くのインターネットシステムは、データの同期が数秒遅れても許容できますが、Gitはそれが非常に困難です。
開発者が git push を成功した直後に、次の git fetch でプッシュしたばかりのcommitが見つからないと、クライアントは異常な状態になります。100台のCIランナーが同時にcloneした際、そのうちの数台がテスト対象のcommitを読み取れないと、ランダムで再現困難な失敗が発生します。
したがって、大規模なGitホスティングは、一見矛盾する3つの要件を同時に満たす必要があります。ローカルのGit操作が高速であること、読み取りが水平方向にスケールできること、そしてすべてのレプリカが、公開済みのリポジトリ履歴に対して整合性を保つことです。
2. 歴史的変遷：先人たちはどのような問題に直面したか
この記事の最も価値ある部分の1つは、Continuityがどれほど先進的かを直接宣言するのではなく、まず数世代にわたるアーキテクチャがなぜ失敗したかを振り返っていることです。これにより、Cursorのソリューションが一体何を解決したのかを理解できます。
1. 分散オブジェクトストレージ：保存は洗練されているが、cloneが遅すぎて受け入れられない
Google/JGitチームは、Gitオブジェクトを分散ハッシュテーブル（DHT）に格納する試みをしました。通常の操作は実行できましたが、DAGのシリアル読み取りコストが高く、さらに致命的だったのは、サーバー内部がどのように保存していても、Gitクライアントは最終的にネットワークを介してpackfileを受け取る必要があることです。
これはつまり、サーバーが分散したオブジェクトを再走査し、フィルタリングし、圧縮してpackにまとめなければならないことを意味します。Shawn Pearce氏のその後の総括によると、linux-2.6リポジトリの一度のcloneには15分から30分かかる可能性がありました。チームは最終的にオブジェクトレベルのDHTを放棄し、ネイティブなpackとindexを保持することにしました。
この失敗は、GitオブジェクトがSHAによるアドレス指定に適していることと、完全なGitワークロードがオブジェクトレベルのリモートアクセスに適していることは別問題であることを示しています。
2. 分散ファイルシステム：Gitを保持したが、ローカルの前提もすべて保持した
GitHubは初期に、NFS、GFS/GFS2、DRBDなどのファイルレベルまたはブロックレベルのレプリケーション方式を試しました。その考え方は非常に実用的でした。RailsアプリケーションもGitリポジトリも変更せず、基盤となるファイルシステムだけを分散させるというものです。
問題は、Gitのデフォルト実装が、ローカルファイルのロック、同期、アトミック更新、キャッシュについて多くの前提を置いていることです。また、packfileのランダムリードは、一度の操作を多くのネットワークジャンプに分割します。動作が遅すぎて停止しないようにするには、packfile全体を可能な限りローカルにキャッシュする必要がありますが、同じファイルシステムが数十万のリポジトリを収容する必要がある場合、この方法は持続不可能です。
GitHubはその後、よりシンプルな方法に戻りました。通常のGitリポジトリを専用ファイルサーバーのローカルディスクに保存し、RailsがRPCを介してリポジトリがあるマシンに操作を送信するというものです。これによりネイティブなGitパフォーマンスは維持できましたが、単一のリポジトリが1台のマシンに制限されるという問題は残りました。
3. Spokes：初めてパフォーマンスと整合性を同時に維持
2013年頃、GitHubは後にSpokesとして知られるシステムを開発しました。これは、現代のGitホスティングの基本的な形態を確立しました。
- 各レプリカはNVMe上のネイティブなGitリポジトリです。
- データはpackfileレベルで複製され、Gitのオブジェクトモデルは書き換えません。
- すべての重要なレプリカは同期して整合性を保ち、読み取りは任意のレプリカに委ねられます。
1回のpushには2つの部分が含まれます。packfileは新しいオブジェクトを保存し、参照トランザクションはブランチを新しいcommitにポイントさせます。Spokesは、まず比較的大きなpackを非同期でレプリカにファンアウトし、その後、3フェーズコミット（3PC）を使用して非常に小さな参照トランザクションを調整できます。大多数のノードが確認した後、参照が実際にコミットされ、pushがクライアントに成功を返します。
操作方法：参加ノードをクリックし、スライダーでレプリカ数と片道レイテンシを変えます。
5個のレプリカすべてが調整経路に入り、レイテンシがコミット周期を延ばします。示すのは因果関係だけで、本番スループットは推計しません。
Spokesが長年稼働したのは、それが「時代遅れ」だからではなく、ローカルGit、packfile、強整合性を正しく保持していたからです。Continuityも後にこれらの選択を覆すことはありませんでした。
本当の問題は、Spokesの各重要レプリカが同時に3つの責任を負っていたことです。
- clone、fetch、Web UI、APIリクエストにサービスを提供する。
- 失われてはならない永続データを保存する。
- 各pushの書き込み調整に参加する。
人気のあるモノレポの場合、3つのレプリカではCIにサービスを提供するには不十分であり、レプリカを増やすとより多くのノードが3PCに参加することになり、pushが最も遅いノードに引きずられやすくなります。エージェントが作成する大量の低トラフィックで使い捨ての小規模リポジトリの場合、3つの常時オンラインレプリカは深刻な無駄です。
したがって、原文のSpokesに関する要約は非常に正確です。レプリカ数の下限は常に高すぎ、上限は常に低すぎる。
さらに、ディスク上のレプリカ自体が信頼できる情報源でした。プラットフォームは、各リポジトリがどのマシンにあるかを記録する外部ルーティングテーブルを使用し、チェックサムを継続的にチェックし、破損を検出して迅速に修復する必要がありました。各レプリカは注意深く世話をしなければならない「ペット」のようなもので、壊れたからといってすぐに捨てて再構築することはできません。
3. Cursorの解決策：Continuityアーキテクチャ
CursorがOriginのために自社開発したContinuityの核心は、Gitを捨てることでも、commit、tree、blobをすべて直接S3オブジェクトとして保存することでもありません。
これはSpokesの最も成功した部分を保持しています。ローカルNVMe上で引き続き通常のGitリポジトリが動作し、clone、fetch、参照トランザクション、repackは引き続き成熟したGitツールチェーンを使用します。本当に変わったのは、リポジトリの真の状態を定義する資格を持つものが誰かということです。
| アーキテクチャの側面 | Spokes | Continuity |
|---|---|---|
| 信頼できる情報源 | 複数の重要ノード上のディスクGitリポジトリ | S3互換オブジェクトストレージ内のWAL |
| ローカルリポジトリの役割 | サービスレプリカ、永続レプリカ、コンセンサス参加者 | 再構築可能な高性能ホットキャッシュ |
| 書き込み整合性 | マルチレプリカ3PCによる参照トランザクション調整 | ローカルトランザクション準備 + S3 ETag条件付き書き込み |
| ルーティング | 外部データベースがリポジトリのレプリカ位置を記録 | Rendezvous hashingによる優先ノードの算出 |
| 読み取りスケーリング | レプリカを増やすと調整コストも増加 | サービスレプリカはトラフィックに応じて独立して追加・回収可能 |
Spokesでは、「リポジトリがどこにあるか」は、どのマシンが重要レプリカを保持しているかを知る必要があることを意味しました。Continuityでは、リポジトリは最終的にWALに存在します。任意の健全なノードがログを読み取り、ローカルなGitリポジトリを復元できます。
Rendezvous hashingは、キャッシュヒット率を向上させ、書き込み競合を減らすために、同じリポジトリを安定して一連の優先ノードにマッピングします。ただし、このマッピングはパフォーマンスのみを担当し、正確性は担当しません。ノードリストが一時的に不一致でも、最悪の結果は別のマシンがリポジトリを再構築することであり、2つの相反する履歴が現れることではありません。
Continuityが本当に成し遂げたのは、責務の分離です。
- S3 WALは、永続性、完全な操作順序、復元の根拠を担当します。
- ローカルGitリポジトリは、Git操作の高速実行を担当します。
- レプリカ数は、現在の読み取りトラフィックに一致することのみを担当します。
4. Continuityの主要な技術実装
1. WALファースト：1回のpushが正式に有効になる場所
1回の書き込みは、おおよそ6つのステップを経ます。
- フロントエンドがクライアントからアップロードされたpackfileと参照トランザクションを受け取ります。
- packfileはローカルリポジトリに書き込まれ、同時に不変のWALエントリとしてS3にアップロードされます。
- ローカルGitが参照トランザクションを準備し、古い値を検証して参照をロックしますが、まだコミットはしません。
- フロントエンドがS3上のWALインデックスと現在のETagを読み取ります。
- フロントエンドが新しいエントリのポインタをインデックスに追加し、
If-Match条件付き書き込みで書き戻します。 - インデックスの更新が成功すると、ローカルの参照トランザクションがコミットされ、サーバーがpushを確認します。
ステップ5が線形化ポイントです。2つのフロントエンドが同時にWALエントリをアップロードする可能性がありますが、同じ古いETagでインデックスを更新しようとすると、1つだけが成功します。失敗した方は 412 Precondition Failed を受け取り、最新のインデックスを読み直し、自分の書き込みを次の位置に並べて再試行します。
操作：段階を選ぶか、再生・ステップで確認。
フロントエンドがpackfileを受信し、インデックスを構築。
キーが異なる不変オブジェクトは上書きしません。
これは、複数の重要レプリカが参加していた書き込み調整を、非常に小さなWALインデックスオブジェクトに対する比較と交換（CAS）に集約することを意味します。正常な状態では、優先ノードが競合を減らせます。フェイルオーバー時も、正確性はS3の条件付き書き込みによって決まり、特定のマシンが常にプライマリノードであることに依存しません。
2. UDP Gossip + ETag：メッセージは失われても、履歴は古くならない
書き込みが完了すると、プライマリノードはUDP gossipを介して他のレプリカにWALへの追い付きを事前に通知します。UDPはパケットロスや順序の乱れが発生する可能性があり、通知をそのリポジトリを担当しなくなったノードに送信することもありますが、これはパフォーマンス最適化のみを担い、正確性は担いません。
各レプリカは、実際にfetchやcloneを処理する前に、ローカルに記録したETagを使ってS3に対して条件付き読み取りを実行します。
304 Not Modifiedが返ってきた場合：WALインデックスに変更がないため、ローカルレプリカは最新の状態であり、そのままサービスを提供できます。200 OKが返ってきた場合：S3に新しいバージョンのインデックスが存在するため、レプリカはまず新しいインデックスをダウンロードし、不足しているWALを再生してから、クライアントに応答します。
操作方法：「UDP gossipを破棄」を切り替えて段階的に再生し、304の高速経路と200の追随経路を比較します。
プライマリはまず、新しいWALエントリとインデックスをS3にコミットします。
現在の経路：gossipが届き、レプリカは先に追随します。fetch時の条件付きGETは304を返します。
原著によると、このS3のメタデータのみを確認する304リクエストは、平均10ミリ秒未満です。これはCursor自身の本番環境での観測結果であり、AWSがすべてのリージョンと負荷に対して保証する普遍的なレイテンシーではありません。
3. 弾力性のあるレプリカ：0個から数百個まで、トラフィックに応じて変動
WALが信頼できる情報源となって初めて、ローカルリポジトリは本当の意味でのキャッシュになります。
- 人気のあるMonorepoは、数十から数百のサービスレプリカに増やして、clone、fetch、Web UI、REST API、Agent RPCの負荷を分散できます。
- 一般的なリポジトリは、ローカルレプリカが1つだけで十分な場合があります。
- 長期間トラフィックのないリポジトリは、ノードのディスクから再利用のために削除され、ローカルレプリカの数は0になります。次回アクセスがあったときに、WALから再構築されます。
ここでの「0レプリカ」は、ローカルにサービスキャッシュが存在しないという意味であり、リポジトリのデータが消えたわけではありません。原著では、すべてのリポジトリが「秒単位で復旧」できるとは約束していないため、再構築速度を普遍的な保証として記述することはできません。
4. 単一ノードでの圧縮：繰り返されるCPU処理をネットワーク帯域に置き換え
pushのたびに新しいpackfileが生成されます。packが増え続けると、単発のインデックス検索が高速でも、それが数百回、数千回と繰り返されるとGitの動作が遅くなります。そのため、リポジトリは定期的にrepackを行う必要があります。
Spokesの複数の重要なレプリカが、CPU負荷の高い圧縮処理を重複して実行する可能性があります。Continuityでは、現在のプライマリノードだけがrepackを実行し、その圧縮結果をローカルリポジトリとWALの両方に適用します。他のレプリカは再計算を行わず、S3から圧縮済みのpackをダウンロードするだけで、繰り返しの計算をネットワーク帯域に置き換えます。
操作方法：ホット／コールドの変化を再生するか、packを1つずつ追加してcompactionを実行し、境界の移動を確認します。
破線の空き枠はローカルキャッシュが回収されたことを示します。リポジトリの事実はS3 WALに残り、レプリカとともに消えるわけではありません。
#98 a1.wal
#99 b7.wal
追加または圧縮のたびに、まずWALインデックスを更新します。しきい値に達すると、プライマリが複数の小さなpackを1個の大きなpackにまとめます。
5. WALのもう一つの価値：完全なトレーサビリティとリカバリ
本番環境のGitリポジトリでは、保存データの破損、repackの欠陥、pushの競合状態、Git自体のエッジケースによるエラーが発生する可能性があります。Continuityはすべてのpushイベントと圧縮イベントをWALに書き込むため、リポジトリが経てきたすべての基本状態を追跡できます。
レプリカは最新の状態に前方回復できるだけでなく、エラーが発生する前の状態にロールバックすることもできます。エンジニアは、どのpushまたはrepackが問題を引き起こしたかを特定し、操作ログからリポジトリを再構築できます。
これは、「packfileをオブジェクトストレージに、refsをリレーショナルデータベースに保存する」という方式とContinuityが異なる重要な点です。Continuityは、単一のログで永続化の順序、参照の変更、リカバリ履歴を同時に管理し、厳密に同期させる必要がある2つの権威ある状態を維持することを避けようとしています。
5. パフォーマンス結果と、その数字が証明しないこと
Cursorは、最も顕著な3つの内部テスト結果を公表しています。
- 最大100レプリカでの合成負荷テストでは、読み取りスループットはレプリカ数にほぼ比例して増加し、pushスループットの顕著な低下は見られませんでした。
- S3 Standardを使用した場合、クラスタは圧縮と結果のレプリケーションを並行して行いながら、継続的に最大約120 push/秒を処理できました。
- レイテンシーの低いS3 Express One Zoneを使用した場合、スループットは300 push/秒を超え、ボトルネックはローカルのGit圧縮に移りました。
最初の9個はSVGアニメーションまたはインタラクティブコンポーネントで、静的な図としてそのまま掲載するのに適しているのはこの2枚です。
読み取り：最大100レプリカまでほぼ線形にスケール
これは、レプリカを増やして読み取り容量を拡張できるという限定的な結論を支持します。あらゆる負荷で完全に線形になるという意味ではありません。
書き込み：Standardは最大120 push/s、Expressは300超
オブジェクトストレージのレイテンシは書き込み上限に明確な影響を与え、信頼できるログ層が書き込み性能を制約することを示しています。
証拠の範囲：原文は、テスト用ハードウェア、オブジェクト分布、リクエスト構成、P95/P99、障害注入、長期的な本番SLOを完全には公開していません。これはCursorの自己報告であり、業界全体に通用する保証ではありません。
これらの数字が支持する結論は非常に具体的です。信頼できる情報源をレプリカクラスタの外に出すことで、読み取りレプリカを追加しても、毎回のpushに関与する調整コンポーネントが必ずしも増えるわけではなくなります。Continuityの読み取りと書き込みの分離という方向性は、内部テストで支持を得ています。
しかし、これらの数字は、OriginがGitHubと同等の長期的な本番環境での信頼性を達成したことを直接証明するものではありません。この記事では、完全なハードウェア構成、リポジトリのオブジェクト分布、pushサイズ、リクエストミックス、P95/P99レイテンシー、フォールトインジェクション、リージョン間の障害復旧、長期的なSLO、再現可能な実験データは公開されていません。テスト対象は主にCursor自身のMonorepoであるeverysphereです。
したがって、「読み取りはほぼ線形にスケールする」という表現は「完全に線形にスケールする」よりも正確であり、「アイドル状態のリポジトリはWALから再構築できる」という表現も「次回のアクセス時には必ず秒単位で復旧する」よりも正確です。
製品レイヤーに戻ると、ContinuityはCursor Originコードホスティングプラットフォームの技術基盤です。Cursorの見解では、エージェントがより多くのコード、PR、CI実行、使い捨てリポジトリを生成するため、バージョン管理は開発者がたまに操作するツールから、多数の自動化システムが継続的に競合する調整レイヤーへと変化します。
この記事が実際に示しているのは、Cursorがより高速なGitバックエンドを開発したということだけではありません。それは、Cursorがその責任の境界を広げているということです。開発者がコードを生成するのを支援することから、開発者に代わってソフトウェアの履歴を保存することへと向かっています。
アーキテクチャ設計は明確に説明され、内部データもその方向性が実現可能であることを示しています。しかし、コードホスティングが最終的に信頼されるかどうかは、優れたエンジニアリング記事によるものではなく、何年にもわたって、日常的で、退屈で、ニュース価値のないすべてのpushが、完全に取り出し可能であり続けるかどうかによるのです。
Continuityが解くGitホスティング
S3 WALが事実を持ち、NVMe Gitは増減・再構築できる高速キャッシュになります。
Gitには「ローカル引力」がある
DAGは順番に参照し、packfileはランダムに読みます。push直後の可視性も必要で、ネットワークが両方のコストを増幅します。
Spokesは3役をレプリカに固定する
Gitと3PCは速度と強整合性を保ちますが、各レプリカがサービス、永続化、書き込み調整を同時に担います。
事実をレプリカから外す
ContinuityはGitを残し、権威だけを移します。S3 WALが順序と復旧情報を持ち、ローカルNVMe Gitは実行を担います。
2つの保証：順序と鮮度
正しさはS3の条件付き操作が担い、gossipは追従を速めるだけです。
有望だが、未証明
レプリカは0〜100以上へ伸縮。ただし公開済みはCursorの自己テストで、長期復旧は未検証です。
Git複製の呪縛を解く
管理者ローカルでは高速ですが、規模が大きくなると読み書きも履歴も盤石に保つ必要があります。
問題は「Gitをサーバーに置くこと」ではなく、大規模でも高速で整合性を保つことです。
管理者次の鍵は、この読み取りの結果の中に隠れているのです。
オブジェクトのSHAアドレス指定は有効でも、Gitのワークロードにオブジェクト単位のリモートアクセスは不向きです。
管理者リポジトリは分割されていませんが、ランダムアクセスのたびにネットワークを越えています。
ネットワークファイルシステムはGitを維持しますが、ローカルロックやアトミック更新、低遅延のランダム読み取りといったGitの前提もそのまま維持します。
管理者レプリカの下限が高すぎ、上限が低すぎます。サービスノードを増やすたびに調整の負担も増えます。
Spokesはローカル性能と強整合性を守りますが、サービス、耐久性、各pushの調整を同じ重要レプリカ群に縛り付けます。
管理者サービスレプリカに真実を持たせない。真実はWALへ、ローカルGitは高速実行に専念させる。
ContinuityはネイティブGitを捨てず、リポジトリの真の状態を定義する権限を変えたのです。
管理者台帳が一意の順序を決定し、その後でローカル参照がコミットされます。衝突した書き込みは再読み取り後に再試行です。
ETag条件付き書き込みは線形化ポイントです。成功者は進み、失敗者は412を受け取り、新しいインデックスを読んで再試行します。
管理者需要が高ければ追加、低ければ削除です。捨てるのはキャッシュであり、リポジトリの履歴ではありません。
レプリカ数はついに読み取りトラフィックにのみ追従します。多数にスケールアウトも、ローカルサービスレプリカゼロへの縮退も可能です。
管理者方向性を支持するデータはありますが、一般的な信頼性を保証するにはまだ足りません。
100レプリカ、約120 push/s、300 push/s超はすべてCursorの自己申告によるテストであり、あらゆる負荷や環境への普遍的な約束ではありません。