C4モデルの実例：Stripe、Netflix、Uber、Revolut

ネットで見つかるC4モデルの例は、たいていおもちゃのようなシステムが1つだけです。銀行、ECサイト、ボックスが3つとデータベースが1つのインターネットバンキングアプリ。記法はわかります。けれども、本当に難しいところは見せてくれません。実際のシステムに何百ものサービスがあるとき、何を省くかを決めるという部分です。

このページでは、より規模の大きな4つのC4モデルの例を集めました。どれもコンテキストからコンポーネントまでモデリングしています。Stripeのカード決済、Netflixの再生リクエスト、Uberの配車リクエスト、Revolutの国際送金です。それぞれにレベル1のダイアグラム、レベル2と3へどうズームしていくかの短い要約、そして詳細記事へのリンクを付けています。最後には、そのままコピーできる小さな例と、4つに共通する点のまとめがあります。

出典について。 4つの例はすべて、私たちの「Anatomy of」シリーズから取ったもので、いずれも各社の公開情報のみに基づいています。エンジニアリングブログ、カンファレンスでの講演、オープンソースのリポジトリ、求人情報、外部のケーススタディです。どれも当該企業の公式なアーキテクチャドキュメントではありません。各詳細記事では、企業が明言していることではなく推測した部分を明示しています。

C4モデル自体が初めてなら、まずC4モデルとは何かを読んでください。4つのレベル別ガイドでは、各ダイアグラムの種類をさらに掘り下げています。System Context、Container、Component、Codeです。

良いC4の例とは

C4ダイアグラムの例が役に立つのは、形だけでなく、そこから判断を学べるときです。以下の4つは同じルールに沿って書かれています。どれかを見る前に、そのルールを盗んでおく価値があります。

ユーザーの1つのアクションを追う。 どの例も会社全体をドキュメント化しようとはしていません。ユーザーが行う1つのこと（決済、再生、配車、送金）を選び、そのアクションが触れるものだけを描いています。だからこそ、1,000ものサービスを抱える環境でも、読める1ページに収まるのです。

レベル1はボックス10個程度に抑える。 System Contextのレベルでは、Netflixのような会社も1,000のマイクロサービスではありません。いくつかのプロダクトシステムと、それを取り巻く外部アクターです。レベル1のダイアグラムにボックスが40個必要なら、境界を引く高さが間違っています。

レベル2では1つの経路にズームする。 コンテナ図には、その1つのアクションの経路上にあるコンテナを、テクノロジーとプロトコル付きで描きます。会社が運用しているすべてのコンテナを描くわけではありません。

レベル3のズーム先には理由を持つ。 コンポーネント図を描くのは1つのコンテナだけです。興味深いエンジニアリングがあるコンテナ、あるいは企業が公開情報で誠実にモデリングできるほど詳しく説明しているコンテナを選びます。

ボックスを判断で説明する。 各例には、レベルとレベルのあいだに3つの短いアーキテクチャ決定記録（ADR）を置いています。ダイアグラムは何が存在するかを示します。ADRはなぜそうなっているかを語ります。新しく入ったメンバーが最初に抱く疑問はそこです。

4つの例をひと目で比較すると、次のようになります。

例 追跡するアクション レベル1 レベル2のズーム レベル3のズーム
Stripe カード決済（PaymentIntents.create()） 15のプロダクトシステム Payments core 冪等性レイヤー
Netflix 再生ボタンを押す 10のシステム Streaming Platform Cosmos動画パイプライン
Uber 配車リクエスト（タップからドライバーの承諾まで） 3つのプロダクトプラットフォーム、1つのMarketplace、Foundationプラットフォーム群 Marketplaceのディスパッチ経路 DISCOマッチングエンジン
Revolut EURからGBPへの送金 8つのプロダクトシステム Retail Bankingにおける送金経路 Sherlock不正検知エンジン

例1：Stripe、カード決済

StripeのC4 System Context：15のシステムと外部アクター

Stripeの公開情報に基づくものです。Stripeの公式なアーキテクチャドキュメントではありません。

レベル1。 System Contextで見ると、Stripeは「決済API」ではありません。私たちのモデルでは、1つの基盤を共有する15のプロダクトシステムが現れます。Payments、Connect、Billing、Radar、Issuing、Treasuryなどです。その周囲には、加盟店、カード会員、カードネットワーク、代替決済手段、アクワイアラーとイシュアーの銀行、銀行パートナー、そしてAWSがあります。

レベル2。 コンテナ図ではPaymentsのボックスを開き、1回のPaymentIntents.create()呼び出しを追います。APIゲートウェイ、状態を変更するすべてのエンドポイントの前に置かれた冪等性レイヤー、PaymentIntentのステートマシン、カードデータのボールト、並行して走るRadarのスコアリング、ネットワークコネクター、台帳、Webhookの配信です。

レベル3。 コンポーネントのズームは冪等性レイヤーの内部に入ります。スタックの中で最も詳しく公開されている部分だからです。リクエストハッシャー、PostgreSQL上のキーストア、フェーズエグゼキューター、そしてリトライされたリクエストが中断した地点から再開できるようにするリカバリーポイントトラッカーです。

ここから学べること。 コンポーネント図を学ぶならこの例です。レベル3のビューはクラスの一覧ではなく、読み手が推論できるステップの連なりになっています（「外部への副作用はすべて2つのリカバリーポイントのあいだにある」）。

詳細記事：Anatomy of a Charge：StripeをC4でモデリングする

例2：Netflix、再生リクエスト

NetflixのC4 System Context：10のシステムと外部アクター

Netflixの公開情報に基づくものです。Netflixの公式なアーキテクチャドキュメントではありません。

レベル1。 Netflixの公開資料からは、10のシステムが一貫して浮かび上がります。Member Experience、Content Discovery、Streaming Platform、Open Connect、Studio Engineering、Content Engineering、Data Platform、Cloud Platform、Security、Ads Platformです。外部アクターには、会員のデバイス、Open Connectアプライアンスを設置しているISP、AWS、DRMプロバイダー、決済パートナー、コンテンツスタジオが含まれます。

レベル2。 コンテナのズームではStreaming Platformを開き、再生リクエストを追います。Playback API、マニフェストサービス、DRM用のライセンスサービス、メッセージセキュリティレイヤー、EVCacheの層、そしてその背後にあるCassandraクラスターです。マニフェストがデバイスをOpen Connectアプライアンスへ向かわせます。CDNを自前で構築するというレベル1の判断が、ここで再び姿を現します。

レベル3。 コンポーネントのビューは、動画エンコーディングパイプラインのCosmosに入ります。Cosmosはリクエスト時の再生経路上にはありません（エンコーディングは作品が取り込まれるときに行われます）。記事でもそのことをはっきり書いています。それでも選んだのは、Netflixが各ステップに名前を付けられるほど多くの情報を公開しているからです。検査、複雑度分析、ラダー生成、エンコーディング、検証、品質スコアリングです。

ここから学べること。 レベル1で「1,000ではなく10」を最もはっきり示している例です。また、レベル3のズームが追跡している経路から外れるとき、それを認める良い例でもあります。

詳細記事：Anatomy of a Play：NetflixをC4でモデリングする

例3：Uber、配車リクエスト

UberのC4 System Context：Mobility、Delivery、Freight、Marketplace

Uberの公開情報に基づくものです。Uberの公式なアーキテクチャドキュメントではありません。

レベル1。 System ContextでのUberは、共有された1つのMarketplaceの上に乗る3つのプロダクトプラットフォーム（Mobility、Delivery、Freight）と、その下にあるFoundationプラットフォームの層です。Foundationには、Maps、Payments、アイデンティティとリスク、コミュニケーション、MLプラットフォーム、ワークフローエンジン、ストレージ、ストリーミング、オブザーバビリティ、コンピュートが含まれます。外部アクターは、乗客、ドライバー、注文者、配達員、加盟店、決済ネットワーク、通信キャリア、そして都市の規制当局です。

レベル2。 コンテナのズームでは、Marketplaceのディスパッチ経路に沿って配車リクエストを追います。エッジゲートウェイ、各トリップをワークフローインスタンスとして実行するトリップオーケストレーター、マッチングエンジン、ダイナミックプライシング、ETAサービス、ドライバーの状態、ストレージレイヤー、そしてKafkaです。

レベル3。 コンポーネントのビューはマッチングエンジンを開きます。座標をH3の六角形インデックスに変換するリクエストノーマライザー、供給スキャナー、リングエクスパンダー、候補ランカー、割り当てソルバー、通知ディスパッチャー、そしてフォールバック経路です。

ここから学べること。 すべてのプロダクトを描かずに、プラットフォーム企業をレベル1で描く方法を示す例です。中央にある共有Marketplaceは、どんなサービス一覧よりもUberのアーキテクチャについて多くを語ってくれます。

詳細記事：Anatomy of a Ride：UberをC4でモデリングする

例4：Revolut、国際送金

RevolutのC4 System Context：プロダクトシステムと外部アクター

Revolutの公開情報に基づくものです。Revolutの公式なアーキテクチャドキュメントではありません。

レベル1。 公開情報からは、少なくとも8つのプロダクトシステムが読み取れます。Retail Banking、Business Banking、FX、Wealth and Trading、Credit、FinCrime、Onboarding and KYC、そしてイベント基盤を備えたコア台帳です。その周囲には、カードネットワーク、決済レール（Faster Payments、SEPA、SWIFT）、提携銀行、規制当局、Google Cloudがあります。このダイアグラムは、組織図では見えないことを1つはっきりさせます。FinCrimeにはすべてのプロダクトから矢印が伸びており、すべてのプロダクトのクリティカルパス上にあるということです。

レベル2。 コンテナのズームでは、Retail Bankingを通るEURからGBPへの送金を追います。モバイルアプリ、APIエッジ、明示的なステートマシンを持つ送金オーケストレーター、PostgreSQL上の複式簿記の台帳、FXエンジン、FinCrimeパイプライン、決済レールごとに1つのコネクター、イベントストア、そして通知です。

レベル3。 コンポーネントのビューは、不正検知エンジンのSherlockを開きます。特徴量の組み立て、インメモリのプロファイルストア、モデルサーバー、判定ポリシー、夜間の再学習、そしてアナリストからのフィードバックループです。

ここから学べること。 4つの中で最も網羅的な例です。レベル1と2のあいだにステップごとのタイムラインを加え（レイテンシは公開値ではなく説明用だと明記しています）、さらに「真似すべきこと、避けるべきこと」のセクションで、10サービス規模のチームがどの判断を取り入れ、どれを取り入れるべきでないかを述べています。

詳細記事：Anatomy of a Transfer：RevolutをC4でモデリングする

コピーして使える小さな例

上の4つの例は、あえて大規模なものにしています。たいていのシステムはそうではありません。そこで、有用な3つのレベルすべてを備えた小さなC4モデルの例を用意しました。私たちのC4モデル完全ガイド全体で使っているECプラットフォームです。形をコピーして、ボックスの名前を付け替えてください。

レベル1：System Context

[Customer] --> [E-Commerce Platform] : Browses products, places orders
[Warehouse Staff] --> [E-Commerce Platform] : Manages inventory
[E-Commerce Platform] --> [Payment Gateway (Stripe)] : Processes payments
[E-Commerce Platform] --> [Shipping Provider (FedEx API)] : Creates shipments
[E-Commerce Platform] --> [Email Service (SendGrid)] : Sends notifications

2種類のユーザー、3つの外部システム、そして自分たちが所有するものすべてを表す1つのボックスです。

レベル2：Container

[Single-Page Application (React)] --> [API Gateway (Kong)] : Makes API calls (HTTPS/JSON)
[API Gateway] --> [Order Service (Go)] : Routes requests
[API Gateway] --> [Product Service (Go)] : Routes requests
[API Gateway] --> [User Service (Go)] : Routes requests
[Order Service] --> [Order Database (PostgreSQL)] : Reads/writes orders
[Product Service] --> [Product Database (PostgreSQL)] : Reads/writes products
[User Service] --> [User Database (PostgreSQL)] : Reads/writes users
[Order Service] --> [Message Queue (Kafka)] : Publishes order events
[Notification Service (Go)] --> [Message Queue] : Consumes order events

すべてのボックスにテクノロジーを、すべての矢印にプロトコルか目的を書き、データストアもコンテナとして描いています。

レベル3：Component（Order Serviceの内部）

[Order Handler] --> [Order Service] : Delegates business logic
[Order Service] --> [Order Repository] : Persists orders
[Order Service] --> [Payment Client] : Validates payment
[Order Service] --> [Inventory Client] : Checks stock availability
[Order Repository] --> [Order Database (PostgreSQL)] : SQL queries
[Payment Client] --> [Payment Gateway (Stripe)] : HTTPS/REST
[Inventory Client] --> [Product Service] : gRPC

コンポーネント図を描くのは1つのコンテナだけ。4つの大きな例と同じルールです。Product ServiceとUser Serviceは単純なCRUDなので、内部を描いてもフォルダ一覧以上のことは何も伝わりません。

こうした選択の理由については、レベル別ガイドを参照してください。System Context図に何を載せるべきか、Container図に何を載せるべきか、そしてComponent図を描く価値があるのはいつかです。ここではレベル4を省きました。ほとんどのチームが省くのと同じ理由です。それが役に立つのはどんなときかはCode図のガイドで説明しています。

4つに共通すること

並べてみると、4つの例は同じいくつかの習慣に従っています。どれもC4モデルそのもののルールではありません。これらのモデルを読みやすくしたのが、この習慣です。

レベル1はおよそ10ボックス。 Stripeは15、Netflixは10、Revolutは8。Uberは1つのMarketplaceの上に3つのプロダクトプラットフォーム、その下にFoundationプラットフォーム群です。どの会社も小さくはありません。それでもレベル1のダイアグラムが小さいままなのは、サービス単位ではなくプロダクトシステム単位でまとめているからです。

レベル2は1つの経路。 どのコンテナ図も、1つのアクションが通過するコンテナだけを示しています。StripeのコンテナビューにはBillingやAtlasのコンテナはありません。NetflixのビューにはStudio Engineeringのものが何もありません。これは抜け漏れではありません。それらのコンテナは、別のアクションのための別のダイアグラムに載るべきものです。

レベル3は1つのコンテナを、誠実に選ぶ。 コンポーネントのズームは常に、実際のコンポーネントを描けるほど公開ドキュメントが充実しているところに向かいます。Netflixの記事は、Cosmosがリクエスト時の再生経路から外れていることを率直に書いています。こうした選択を隠す例は、間違った教訓を教えてしまいます。

外部システムは内部システムと同じくらい重要。 カードネットワーク、ISP、決済レール、通信キャリア。4つのどれでも、最も重要なボックスのいくつかは、その会社が所有していないものです。Revolutの決済レールのコネクターは、障害をエンジニアリングで取り除けないコンテナであり、それを見えるようにするのがダイアグラムです。

判断はボックスのすぐ隣に置く。 各例には3つのADRがあり、それぞれが新しく来た人が意外に思うボックスを説明しています。他の動画配信サービスが商用CDNを使うところでNetflixがOpen Connectを持っている理由、RevolutにKafkaがない理由、StripeがMongoDBから移行せずにその上に構築した理由です。その書き方を知りたければ、アーキテクチャ決定記録の完全ガイドで解説しています。

すべてのボックスにオーナーがいる。 各記事は、モデルの最後にオーナーシップマップを載せています。どのチームがどのシステムやコンテナを所有しているかです。これが、ダイアグラムを「誰かが正しく保つ責任を負うもの」に変えるステップです。

自分のシステムをモデリングする

ここに書いたことを当てはめるのに、Stripeほどの取引量もUberほどのサービス数も必要ありません。10サービスのシステムでも同じ手順が使えます。

  1. 重要なユーザーアクションを1つ選ぶ。 チェックアウト、サインアップ、深夜3時に誰かが呼び出される原因になるもの。
  2. レベル1を描く。 自分のシステムを1つのボックスにし、あらゆる種類のユーザーと、そのアクションが触れるすべての外部システムを置きます。ボックスは15個未満を目指します。
  3. その1つのアクションについてレベル2を描く。 通過するコンテナだけを描き、それぞれにテクノロジーを、各矢印に動詞とプロトコルを書きます。
  4. レベル3にするコンテナを1つ選ぶ。 新しく入った人が苦労しそうなものを選び、主なコンポーネントを描きます。
  5. ADRを3つ書く。 誰かが「なぜこうなっているの？」と聞きそうな3つのボックスについてです。
  6. すべてのコンテナにチーム名を付ける。

そして次のアクションで同じことを繰り返します。3つか4つのアクションを終えると、レベル2のダイアグラムが重なり始めます。その重なりこそが、本当のコンテナ図です。

4つの例が見せられないのは、半年後に何が起きるかです。コードは変わったのに、ダイアグラムは変わっていない。archylはまさにその問題を中心に作られています。リポジトリを接続すると、AI発見がシステム、コンテナ、コンポーネント、関係を提案し、あなたはゼロから描く代わりにそれを承認するだけです。その後はドリフトスコアがモデルをコードと照合するので、モデルが古くなったときにそれがわかります。

よくある質問

C4モデルの良い例とは？

C4モデルの良い例は、実際のユーザーアクションを1つ、レベル1から3まで追いかけ、意外に見えるボックスを説明しているものです。このページの4つの例（Stripe、Netflix、Uber、Revolut）はどれもそうなっていて、およそ10システムのレベル1ダイアグラム、1つの経路に絞ったコンテナ図、そして1つのコンポーネントのズームを備えています。小さなシステムなら、上のECサイトの例がテンプレートとして手ごろです。

C4のコンテナ図の例はどこで見られますか？

4つの詳細記事にはそれぞれレベル2のコンテナ図があります。StripeのPayments core、NetflixのStreaming Platform、Uberのディスパッチ経路、Revolutの送金経路です。コンテナと関係の表を含む、より小さな実例については、C4 Container図ガイドを参照してください。

これらはStripe、Netflix、Uber、Revolutの公式なアーキテクチャ図ですか？

いいえ。どのモデルも各社の公開情報のみに基づいており、各詳細記事では、明言されている部分ではなく推測した部分を明示しています。これらは、C4モデルが複雑なスタックをどう読みやすくするかを示すためのもので、これらの企業が現在どう運用しているかをドキュメント化するものではありません。

C4の例には4つのレベルすべてが必要ですか？

めったに必要ありません。ここにある4つの例はすべて、レベル1、2、3を描いてそこで止めています。コードレベルのダイアグラムはリファクタリングのたびに変わるので、描くよりもコードから生成するほうがたいてい良い結果になります。実際のC4モデルのほとんどがコンポーネントで止まるのはそのためです。

C4のSystem Context図にはいくつの要素を置くべきですか？

公式な上限はありません。これらの例では、何百、何千ものサービスを持つ企業に対して、レベル1は8から15のシステムと、その外部アクターで構成されています。それよりはるかに多く必要なら、おそらく間違ったレベルでコンテナを描いているか、複数のシステムにまたがるシステムランドスケープのビューが必要です。

自分のシステムをC4でモデリングしてみませんか？ Developerプランならarchylを無料で試せます。クレジットカードは不要です。続けて読む：C4モデルとは？完全ガイド | C4 System Context図ガイド | C4 Container図ガイド | C4 Component図ガイド | C4 Code図ガイド