Exemplos de modelo C4: Stripe, Netflix, Uber e Revolut

A maioria dos exemplos de modelo C4 que você encontra por aí é um único sistema de brinquedo: um banco, uma loja virtual, um app de internet banking com três caixas e um banco de dados. Eles mostram a notação. Não mostram a parte difícil, que é decidir o que deixar de fora quando o sistema real tem centenas de serviços.

Esta página reúne quatro exemplos maiores de modelo C4, cada um modelado do contexto até os componentes: uma cobrança com cartão na Stripe, uma solicitação de reprodução na Netflix, uma solicitação de corrida na Uber e uma transferência internacional no Revolut. Cada um vem com seu diagrama de nível 1, um breve resumo de como ele desce aos níveis 2 e 3 e um link para a análise completa. No final há um pequeno exemplo que você pode copiar e uma lista do que os quatro têm em comum.

Uma nota sobre as fontes. Os quatro exemplos vêm da nossa série "Anatomia de", e cada um se baseia inteiramente nas comunicações públicas da empresa: blogs de engenharia, palestras em conferências, repositórios open source, vagas de emprego e estudos de caso externos. Nenhum deles é um documento de arquitetura oficial da empresa em questão. Cada post completo indica onde os detalhes foram inferidos em vez de declarados pela empresa.

Se o modelo C4 é novidade para você, leia primeiro o que é o modelo C4. Os quatro guias por nível aprofundam cada tipo de diagrama: contexto de sistema, container, componente e código.

O que faz um bom exemplo C4

Um exemplo de diagrama C4 é útil quando você consegue tirar dele uma decisão, não apenas uma forma. Os quatro abaixo foram escritos com as mesmas regras, e vale a pena roubá-las antes mesmo de olhar qualquer um deles.

Siga uma única ação do usuário. Nenhum desses exemplos tenta documentar a empresa inteira. Cada um escolhe uma única coisa que o usuário faz (uma cobrança, uma reprodução, uma corrida, uma transferência) e desenha apenas o que essa ação toca. É isso que reduz um parque de mil serviços a uma página legível.

Mantenha o nível 1 em torno de dez caixas. No nível System Context, uma empresa como a Netflix não é mil microsserviços. É um punhado de sistemas de produto e os atores externos ao redor deles. Se o seu diagrama de nível 1 precisa de quarenta caixas, as fronteiras estão traçadas na altura errada.

No nível 2, dê zoom em um único caminho. O diagrama de containers mostra os containers no caminho dessa única ação, com tecnologias e protocolos. Ele não mostra todos os containers que a empresa executa.

Escolha o zoom de nível 3 por um motivo. Apenas um container ganha um diagrama de componentes, e é aquele onde está a engenharia interessante, ou aquele que a empresa documentou publicamente com profundidade suficiente para ser modelado com honestidade.

Explique as caixas com decisões. Cada exemplo traz três breves architecture decision records entre os níveis. Um diagrama mostra o que existe. O ADR diz por que tem essa cara, que é a primeira pergunta que um recém-contratado faz.

Veja como os quatro se comparam de relance:

Exemplo 1: Stripe, uma cobrança com cartão

Baseado nas comunicações públicas da Stripe. Não é um documento de arquitetura oficial da Stripe.

Nível 1. No System Context, a Stripe não é "uma API de pagamentos". Nosso modelo mostra quinze sistemas de produto compartilhando uma única base: Payments, Connect, Billing, Radar, Issuing, Treasury e os demais. Ao redor deles estão os lojistas, os portadores de cartão, as bandeiras de cartão, os meios de pagamento alternativos, os bancos adquirentes e emissores, os parceiros bancários e a AWS.

Nível 2. O diagrama de containers abre a caixa Payments e segue uma única chamada PaymentIntents.create(): o API gateway, uma camada de idempotência na frente de cada endpoint que altera estado, a máquina de estados do PaymentIntent, um cofre de dados de cartão, o scoring do Radar em paralelo, os conectores das bandeiras, o ledger e a entrega de webhooks.

Nível 3. O zoom de componentes entra na camada de idempotência, porque é a parte da stack mais documentada publicamente: um hasher de requisições, um key store em PostgreSQL, um executor de fases e um rastreador de pontos de recuperação que permite a uma requisição repetida retomar de onde parou.

O que levar daqui. Este é o exemplo para estudar diagramas de componentes. A visão de nível 3 não é uma lista de classes; é uma cadeia de passos sobre a qual o leitor consegue raciocinar ("todo efeito colateral externo fica entre dois pontos de recuperação").

Post completo: Anatomia de um Charge: modelando a Stripe em C4.

Exemplo 2: Netflix, uma solicitação de reprodução

Baseado nas comunicações públicas da Netflix. Não é um documento de arquitetura oficial da Netflix.

Nível 1. Dez sistemas aparecem de forma consistente no material público da Netflix: Member Experience, Content Discovery, Streaming Platform, Open Connect, Studio Engineering, Content Engineering, Data Platform, Cloud Platform, Security e a Ads Platform. Entre os atores externos estão os dispositivos dos assinantes, os provedores de internet que hospedam os appliances Open Connect, a AWS, os fornecedores de DRM, os parceiros de pagamento e os estúdios de conteúdo.

Nível 2. O zoom de containers abre a Streaming Platform e segue uma solicitação de reprodução: a Playback API, o serviço de manifest, o serviço de licenças para DRM, a camada de segurança de mensagens, um tier EVCache e os clusters Cassandra por trás dele. O manifest aponta o dispositivo para um appliance Open Connect, e é aí que reaparece a decisão de nível 1 de construir uma CDN.

Nível 3. A visão de componentes entra no Cosmos, o pipeline de codificação de vídeo. Ele não está no caminho da reprodução no momento da requisição (a codificação acontece quando um título é ingerido), e o post diz isso. Foi escolhido porque a Netflix publicou o suficiente sobre ele para nomear cada etapa: inspeção, análise de complexidade, geração da ladder, codificação, validação e pontuação de qualidade.

O que levar daqui. A demonstração mais clara de "dez coisas, não mil" no nível 1, e um bom exemplo de como admitir quando o zoom de nível 3 sai do caminho rastreado.

Post completo: Anatomia de um Play: modelando a Netflix em C4.

Exemplo 3: Uber, uma solicitação de corrida

Baseado nas comunicações públicas da Uber. Não é um documento de arquitetura oficial da Uber.

Nível 1. No System Context, a Uber são três plataformas de produto (Mobility, Delivery, Freight) apoiadas em um único Marketplace compartilhado, com uma camada de plataformas Foundation por baixo: Maps, Payments, identidade e risco, comunicações, a plataforma de ML, o motor de workflows, armazenamento, streaming, observabilidade e compute. Entre os atores externos estão passageiros, motoristas, clientes de delivery, entregadores, estabelecimentos, redes de pagamento, operadoras de telecomunicações e reguladores municipais.

Nível 2. O zoom de containers segue uma solicitação de corrida pelo caminho de despacho do Marketplace: o edge gateway, um orquestrador de viagens que executa cada viagem como uma instância de workflow, o motor de matching, a precificação dinâmica, o serviço de ETA, o estado dos motoristas, a camada de armazenamento e o Kafka.

Nível 3. A visão de componentes abre o motor de matching: um normalizador de requisições que transforma coordenadas em índices hexagonais H3, um scanner de oferta, um expansor em anéis, um ranqueador de candidatos, um solucionador de atribuições, o despachante de notificações e um caminho de fallback.

O que levar daqui. O exemplo de como desenhar uma empresa de plataforma no nível 1 sem desenhar cada produto. O Marketplace compartilhado no meio diz mais sobre a arquitetura da Uber do que qualquer lista de serviços diria.

Post completo: Anatomia de uma corrida: modelando a Uber em C4.

Exemplo 4: Revolut, uma transferência internacional

Baseado nas comunicações públicas do Revolut. Não é um documento de arquitetura oficial do Revolut.

Nível 1. As comunicações públicas descrevem pelo menos oito sistemas de produto: Retail Banking, Business Banking, FX, Wealth and Trading, Credit, FinCrime, Onboarding e KYC, e o ledger central com seu backbone de eventos. Ao redor: bandeiras de cartão, trilhos de pagamento (Faster Payments, SEPA, SWIFT), bancos parceiros, reguladores e o Google Cloud. O diagrama deixa óbvia uma coisa que um organograma não mostraria: o FinCrime recebe setas de todos os produtos, então está no caminho crítico de todos eles.

Nível 2. O zoom de containers segue uma transferência de EUR para GBP pelo Retail Banking: os apps móveis, o API edge, um orquestrador de transferências com uma máquina de estados explícita, um ledger de partidas dobradas em PostgreSQL, o motor de FX, o pipeline de FinCrime, um conector por trilho de pagamento, o event store e as notificações.

Nível 3. A visão de componentes abre o Sherlock, o motor antifraude: montagem de features, um profile store em memória, o model server, uma política de decisão, o retreinamento noturno e um ciclo de feedback dos analistas.

O que levar daqui. Este é o exemplo mais completo dos quatro. Ele acrescenta uma linha do tempo passo a passo entre os níveis 1 e 2 (com latências claramente marcadas como ilustrativas, não publicadas) e uma seção "copie isto, pule isto" que diz quais decisões uma equipe com dez serviços deveria copiar e quais não.

Post completo: Anatomia de uma Transferência: modelando o Revolut em C4.

Um pequeno exemplo para copiar

Os quatro exemplos acima são grandes de propósito. A maioria dos sistemas não é, então aqui vai um pequeno exemplo de modelo C4 nos três níveis úteis: a plataforma de e-commerce usada ao longo do nosso guia completo do modelo C4. Copie a estrutura, renomeie as caixas.

Nível 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

Dois tipos de usuário, três sistemas externos, uma caixa para tudo o que é seu.

Nível 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

Cada caixa nomeia sua tecnologia, cada seta nomeia seu protocolo ou finalidade, e os armazenamentos de dados são desenhados como containers.

Nível 3: Component (dentro do 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

Apenas um container ganha um diagrama de componentes, a mesma regra que os quatro exemplos grandes seguem. Os serviços Product e User são CRUD simples, então desenhar o interior deles não acrescentaria nada que a listagem de pastas já não mostre.

Para o raciocínio por trás de cada uma dessas escolhas, veja os guias por nível: o que entra em um diagrama de contexto de sistema, o que entra em um diagrama de containers e quando vale a pena desenhar um diagrama de componentes. Pulamos o nível 4 aqui pelo mesmo motivo que a maioria das equipes pula; o guia do diagrama de código explica quando ele merece seu lugar.

O que os quatro têm em comum

Lado a lado, os quatro exemplos seguem o mesmo punhado de hábitos. Nenhum deles é uma regra do próprio modelo C4. São o que tornou esses modelos legíveis.

Cerca de dez caixas no nível 1. Quinze para a Stripe, dez para a Netflix, oito para o Revolut e, para a Uber, três plataformas de produto sobre um único Marketplace, com as plataformas Foundation por baixo. Nenhuma dessas empresas é pequena. Os diagramas de nível 1 continuam pequenos porque agrupam por sistema de produto, não por serviço.

Um único caminho no nível 2. Cada diagrama de containers mostra apenas os containers por onde uma ação passa. A visão de containers da Stripe não tem containers de Billing ou Atlas. A da Netflix não tem nada de Studio Engineering. Isso não é uma omissão; esses containers pertencem a outro diagrama, para outra ação.

Um único container no nível 3, escolhido com honestidade. O zoom de componentes sempre vai para onde a documentação pública é profunda o suficiente para desenhar componentes reais. O post da Netflix diz abertamente que o Cosmos está fora do caminho da reprodução no momento da requisição. Um exemplo que esconde esse tipo de escolha ensina a lição errada.

Os sistemas externos pesam tanto quanto os internos. Bandeiras de cartão, provedores de internet, trilhos de pagamento, operadoras de telecomunicações: nos quatro, algumas das caixas mais importantes são coisas que a empresa não possui. Os conectores de trilhos do Revolut são os containers cuja falha a engenharia não consegue eliminar, e é o diagrama que torna isso visível.

As decisões ficam ao lado das caixas. Cada exemplo tem três ADRs, e cada ADR explica uma caixa que um recém-chegado acharia surpreendente: por que a Netflix tem o Open Connect onde outros serviços de streaming usam uma CDN comercial, por que o Revolut não tem Kafka, por que a Stripe construiu sobre o MongoDB em vez de migrar para outra coisa. Se você quer o método para escrevê-los, o guia completo de architecture decision records explica.

Toda caixa tem um dono. Cada post encerra seu modelo com um mapa de ownership: qual equipe é dona de qual sistema ou container. É o passo que transforma um diagrama em algo que alguém tem a responsabilidade de manter verdadeiro.

Modele o seu próprio sistema

Você não precisa do volume da Stripe nem da quantidade de serviços da Uber para que tudo isso se aplique. Os mesmos passos funcionam para um sistema com dez serviços:

1. Escolha uma ação do usuário que importa: o checkout, o cadastro, aquilo que faz o pager de alguém tocar às 3 da manhã.
2. Desenhe o nível 1 com o seu sistema como uma única caixa, todos os tipos de usuário e todos os sistemas externos que essa ação toca. Mire em menos de quinze caixas.
3. Desenhe o nível 2 para essa única ação. Apenas os containers por onde ela passa, cada um rotulado com sua tecnologia, cada seta rotulada com um verbo e um protocolo.
4. Escolha um container para o nível 3, aquele com que um recém-contratado teria mais dificuldade, e desenhe seus componentes principais.
5. Escreva três ADRs para as três caixas sobre as quais alguém vai perguntar "por que é assim?".
6. Coloque o nome de uma equipe em cada container.

Depois repita para a próxima ação. Depois de três ou quatro ações, os diagramas de nível 2 começam a se sobrepor, e a sobreposição é o seu verdadeiro diagrama de containers.

O que os quatro exemplos não conseguem mostrar é o que acontece seis meses depois, quando o código mudou e os diagramas não. Esse é o problema em torno do qual o archyl foi construído. Conecte um repositório e a descoberta por IA propõe sistemas, containers, componentes e relacionamentos para você aprovar em vez de desenhá-los do zero, e um drift score confere o modelo contra o código depois, para você descobrir quando ele ficou desatualizado.

FAQ

Qual é um bom exemplo de modelo C4?

Um bom exemplo de modelo C4 rastreia uma ação real do usuário pelos níveis 1 a 3 e explica suas caixas surpreendentes. Os quatro exemplos desta página (Stripe, Netflix, Uber, Revolut) fazem exatamente isso, com um diagrama de nível 1 de cerca de dez sistemas, um diagrama de containers limitado a um caminho e um único zoom de componentes. Para um sistema pequeno, o exemplo de e-commerce acima é um modelo sensato.

Onde encontro um exemplo de diagrama de containers C4?

Cada um dos quatro posts completos tem um diagrama de containers de nível 2: o núcleo de pagamentos da Stripe, a Streaming Platform da Netflix, o caminho de despacho da Uber e o caminho de transferência do Revolut. Para um exemplo menor e completo, com uma tabela de containers e relacionamentos, veja o guia do diagrama de containers C4.

Estes são diagramas de arquitetura oficiais da Stripe, Netflix, Uber e Revolut?

Não. Cada modelo se baseia inteiramente nas comunicações públicas da empresa, e cada post completo indica onde os detalhes foram inferidos em vez de declarados. Eles servem para mostrar como o modelo C4 torna legível uma stack complexa, não para documentar como essas empresas funcionam hoje.

Exemplos C4 precisam dos quatro níveis?

Raramente. Os quatro exemplos aqui desenham os níveis 1, 2 e 3 e param. Diagramas em nível de código mudam a cada refatoração e geralmente é melhor gerá-los a partir do código do que desenhá-los, e é por isso que a maioria dos modelos C4 reais para nos componentes.

Quantos elementos um diagrama de contexto de sistema C4 deve ter?

Não existe um limite oficial. Nestes exemplos, o nível 1 vai de oito a quinze sistemas mais seus atores externos, para empresas com centenas ou milhares de serviços. Se o seu precisa de muito mais, provavelmente você está desenhando containers no nível errado, ou precisa de uma visão de system landscape que cubra vários sistemas.

Quer modelar o seu sistema em C4? Experimente o archyl grátis no plano Developer, sem cartão de crédito. Continue lendo: O que é o modelo C4? Um guia completo | Guia do diagrama de contexto de sistema C4 | Guia do diagrama de containers C4 | Guia do diagrama de componentes C4 | Guia do diagrama de código C4.