Aviso. Este artigo é inteiramente baseado nas comunicações públicas da Uber — seu blog de engenharia, palestras de conferências, repositórios open source e estudos de caso externos. Não é um documento de arquitetura oficial da Uber. Modelamos o que sabemos publicamente para ilustrar como um stack de quatro mil serviços pode ser tornado legível com o modelo C4. Onde detalhes são inferidos em vez de declarados pela Uber, dizemos.

Anatomia de uma corrida: modelando a Uber em C4 com Archyl

Um passageiro toca em Solicitar UberX às 19h23 numa sexta-feira chuvosa em Manhattan. Oito segundos depois, um motorista a 0,4 milha aceitou a corrida, um ETA foi calculado e renderizado, a tarifa está travada, o pagamento está pré-autorizado e um canal em tempo real de baixa latência está aberto entre passageiro e motorista. Quando ele tira os olhos do telefone, o carro já está vindo na direção dele.

Esse único toque, repetido mais de 30 milhões de vezes por dia em 600+ cidades, atravessa dezenas de sistemas da Uber e três redes externas antes do frame zero pousar na tela do motorista.

Em 2024, o stack da Uber rodava aproximadamente 4.000 microserviços, servia picos bem acima de um milhão de requisições por segundo aos seus clientes mobile, agendava compute em seu próprio cluster manager, persistia estado em sua própria camada de storage derivada de MySQL, indexava o planeta em sua própria grade hexagonal, orquestrava milhões de workflows de corridas em seu próprio motor de máquina de estados e treinava modelos de ETA em sua própria plataforma ML.

Como você entende um stack com tantas peças móveis? Como Stripe e Netflix, você não entende — não tudo de uma vez. É exatamente o problema que o modelo C4 foi inventado para resolver.

Neste post seguimos uma única ação de usuário — uma solicitação de corrida do toque até o aceite do motorista — e a observamos atravessar a arquitetura da Uber pelos quatro níveis C4. Não cobriremos cada produto; rastrearemos uma corrida, escreveremos os ADRs que explicam as escolhas que encontramos no caminho e terminaremos com um mapa dos times que possuem cada caixa. Pelo caminho, faremos um tour por cada funcionalidade que o Archyl oferece para tornar esse tipo de modelo — e as políticas em torno dele — realmente mantenível.

Nível 1 — Contexto do Sistema: três plataformas, um Marketplace

No nível Contexto do Sistema, a Uber não é "um app de transporte". São três plataformas de produto sentadas sobre um Marketplace compartilhado e um stack de sistemas Foundation transversais:

1. Mobility — UberX, Uber Black, Uber Pool, Uber Reserve, Comfort, SUV, Premier, parcerias com táxi
2. Delivery — Uber Eats (comida), Uber Direct (delivery-as-a-service para terceiros), Postmates, álcool, mercado
3. Freight — transporte de longa distância, Uber Freight Loadbuilder, ferramentas de broker

Sob eles, a plataforma Marketplace é o cérebro real — o motor de matching, o otimizador de dispatch, o sistema de pricing dinâmico, os forecasters de oferta/demanda. Marketplace é o que torna uma solicitação de corrida em uma corrida.

Sob eles ficam as plataformas Foundation: Maps (routing, ETA, matrizes de distância/duração, tráfego), Payments, Identity & Risk, Communications (push, SMS, mensageria in-app), Notifications, a plataforma ML (Michelangelo), o motor Workflow (Cadence/Temporal), as plataformas Storage (Schemaless, Docstore, Cassandra, stores baseados em RocksDB), as plataformas Streaming (Kafka, uReplicator, Flink), o stack de Observability (M3 metrics, Jaeger tracing, ELK logs) e a plataforma Compute (historicamente Mesos + Aurora → Peloton → baseado em Kubernetes hoje).

Em volta deles, os atores externos: passageiros, motoristas, eaters, couriers, mercadores, shippers e carriers, provedores de mapas (os deles + terceiros para fallback), redes de pagamento e bancos adquirentes, provedores de verificação de identidade, operadoras de telecom para SMS e voz, provedores cloud (a Uber roda híbrido: data centers próprios + AWS/GCP para workloads específicos) e reguladores em nível de cidade.

Três plataformas de produto. Um Marketplace. Dez plataformas Foundation. Tudo o resto é detalhe.

Esse é o presente do Nível 1: no Contexto do Sistema, você não precisa saber que Mobility são duzentos microserviços. Você precisa saber que existe, que conversa com o Marketplace, que o Marketplace conversa com Maps, e que o Cadence orquestra o workflow longo da corrida embaixo. O diagrama é um ponto de partida para conversa, não um inventário.

Funcionalidade Archyl em jogo. Um diagrama de Contexto do Sistema no Archyl é uma única visão C4 Nível 1 com auto-layout, navegação click-through em containers e overlays que permitem silenciar/destacar subconjuntos (ex.: "mostrar apenas plataformas Foundation"). Atores externos são elementos C4 de primeira classe com seu próprio tipo, então renderizam de forma distinta.

ADR-001 · Grade hexagonal H3 para indexação geoespacial

Status · Aceito (2018, open-sourced; ainda ativo em 2026)

Contexto · O motor de matching do Marketplace precisa responder "quais motoristas estão perto deste passageiro?" em milissegundos, em concorrência city-wide, suportando ao mesmo tempo analytics como zonas surge, ETAs e forecasting de oferta. As opções clássicas eram tilings retangulares (Z-order, geohash, células S2 do Google) mas retângulos têm uma falha fundamental para esse domínio: cada retângulo tem mais de uma distância vizinha — cantos estão mais longe que arestas, o que produz aproximações de distância desiguais e queries assimétricas de "o que está perto".

Decisão · Tilar o planeta em hexágonos ao invés disso. Construir uma grade hexagonal hierárquica (H3) com dezesseis resoluções da escala continental até ~1 m². Cada hexágono tem seis vizinhos equidistantes, tornando queries de vizinho-mais-próximo e ring simétricas e rápidas. Open-sourcear a biblioteca para que parceiros e engenheiros da Uber compartilhem a mesma grade.

Consequências · H3 se tornou a primitiva espacial da Uber em Marketplace, Maps, ETA, surge e analytics. O mesmo H3Index é usado em hot paths de dispatch e em jobs offline de forecasting. Também é um dos projetos open source mais bem-sucedidos da Uber — usado por Foursquare, DoorDash, AT&T e incontáveis geo-startups. Os poucos casos onde hexágonos não tilam de forma limpa (as 12 âncoras pentagonais do icosaedro) estão documentados e evitados em código de produção.

No Archyl, é assim que um ADR ganha seu lugar: explica por que a fronteira tem aquela forma. Clique em qualquer container que toca estado geoespacial e o ADR H3 está a um clique.

Funcionalidade Archyl em jogo. ADRs no Archyl são registros de primeira classe ligados a elementos C4 específicos. Aparecem como cards nas caixas relevantes, são filtráveis por status (proposed, accepted, deprecated, superseded) e são enviados para o git como YAML para que vivam ao lado do código. Quando alguém propor substituir H3 em 2030, o ADR existente aparece automaticamente como contexto relacionado.

Nível 2 — Container: zoom no caminho de dispatch do Marketplace

O toque do passageiro pousa no edge da API. Vamos abrir a caixa.

O caminho de dispatch atravessa algo como os seguintes containers:

• Edge gateway — historicamente TChannel + Thrift IDL, hoje um edge gRPC + HTTP/2 para clientes mobile. Faz auth, rate limiting, request shaping e routing.
• Trip orchestrator — roda como um workflow Cadence/Temporal de longa duração. A corrida é uma instância de workflow com transições de estado determinísticas: requested → matched → arriving → on-trip → completed. Retries idempotentes e escalações timer-driven são primitivas integradas, não código bespoke.
• Motor de matching (DISCO) — o otimizador real do marketplace. Dada uma solicitação de passageiro e a oferta de motoristas live dentro de algumas distâncias de ring H3, resolve um problema de atribuição com restrições a cada tick.
• Serviço de pricing dinâmico — combina sinais em tempo real de oferta/demanda para calcular multiplicadores surge por célula H3. Saída um quote de tarifa que é travado no momento da solicitação.
• Serviço ETA — alimenta Maps + modelos ML para rota, tráfego e predição de chegada. Os modelos ETA da Uber se mudaram para deep learning por volta de 2018 e foram refinados todo ano desde então.
• Plataforma Maps — motor de routing in-house da Uber, serviço de matriz de distâncias e pipeline de ingestão de tráfego. Cai para provedores de mapas externos em mercados selecionados.
• Serviço Driver state — rastreia o estado atual de cada motorista (offline, online, em corrida), localização e comportamento de aceitação. Leituras/escritas em dados de localização hot-path via geo-stores customizados.
• Schemaless / Docstore — storage MySQL sharded da Uber. Schemaless é o mais antigo; Docstore é o sucessor mais novo, multi-região, transacional. Estado de corrida, pagamentos, perfis de usuário e a maioria dos dados line-of-business vivem aqui.
• Cluster Kafka — cada transição de estado emite um evento. Marketplace assina para analytics; serviços downstream assinam para fanout (notifications, fraude, contabilidade).
• Canal real-time — uma vez matchado, um canal bidirecional de baixa latência entre os apps de passageiro e motorista para atualizações de localização e chat. Apoiado por gateways long-poll/WebSocket e Kafka embaixo.

O stack tecnológico nesse nível: Go para a maioria dos novos serviços de alto throughput, Java em código antigo do marketplace, Python em pipelines ML e scripts de ops, Node.js em algumas camadas edge, gRPC como o protocolo RPC moderno (TChannel/Thrift foi o predecessor), Cassandra e Redis para latência hot-path, MySQL sob Schemaless/Docstore, Hadoop/HDFS/Hive/Presto para o data warehouse, Spark/Flink para compute batch e streaming.

Uma solicitação de corrida típica toca Edge gateway → Trip orchestrator (Cadence) → Motor de matching (DISCO com queries de ring H3 contra Driver state) → Pricing dinâmico → ETA → fanout Notifications (push ao motorista) → callback driver-accept → canal real-time estabelecido. Tudo isso, com retries, instrumentado end-to-end via Jaeger e medido via M3.

Funcionalidade Archyl em jogo. Diagramas a nível de Container mostram cada container, seu tipo (api / service / database / message_queue / cache / worker / gateway / library / infrastructure), suas tecnologias (extraídas de um catálogo tecnológico por organização) e seus relacionamentos com labels. Contratos de API podem ser anexados a qualquer container e renderizados inline — a Uber linkaria o .proto gRPC para a orquestração de corrida diretamente ao container Trip orchestrator.

ADR-002 · Cadence (Temporal) — construa um motor de workflow, não acumule microserviços stateful

Status · Aceito (~2017, open-sourced como Cadence; spinoff como Temporal)

Contexto · Por volta de 2017, a Uber tinha centenas de microserviços implementando processos de negócio stateful de longa duração — corridas, pedidos, fluxos de signup, onboarding de motoristas, reviews de fraude. Cada um havia crescido sua própria máquina de estado ad-hoc com timers, retries, idempotência e código de recovery. Resultado: cada time pagava o imposto de sistemas distribuídos e os outages frequentemente vinham de bugs sutis na lógica retry/timeout.

Decisão · Não pedir a cada time que invente uma máquina de estado. Construir um motor de workflow genérico com replay determinístico, timers duráveis, retries automáticos, manuseio de signals e um modelo de programação onde o código de workflow lê como lógica de negócio sequencial. Open-sourcear como Cadence. Migrar corridas, signup, reviews de fraude e workflows de movimento de dinheiro para ele ao longo de vários anos.

Consequências · Cadence (e seu fork Temporal, agora usado dentro e fora da Uber) é agora o substrato para todo flow stateful de longa duração na Uber. A abstração "a corrida é um workflow" colapsa milhares de linhas de código bespoke de retry em um punhado de activities bem tipadas. O motor também se tornou um dos projetos de workflow open source mais adotados na indústria. A lição path-dependent: quando dez times estão reimplementando independentemente a mesma primitiva, construa a primitiva.

Funcionalidade Archyl em jogo. Decisões como Cadence se propagam pelo modelo. No Archyl, um ADR pode linkar múltiplos elementos C4 simultaneamente — uma decisão, muitas caixas afetadas. Buscar "workflow" no modelo destaca cada container anotado como consumidor Cadence.

Nível 3 — Componente: dentro do motor de matching

De todos os componentes no stack da Uber, o motor de matching — internamente DISCO — é o mais bem documentado em palestras de conferências e posts de engenharia.

Uma única solicitação de corrida, uma vez que alcança o motor de matching, atravessa estes componentes:

1. Request normalizer — converte as coordenadas do passageiro em um índice H3 em múltiplas resoluções (tipicamente res 9 para hot-path, res 6 para expansão de ring).
2. Supply scanner — consulta o índice driver-state live para todos os motoristas elegíveis dentro de um ring H3 inicial (~500 m). Filtra por tipo de veículo, taxa de aceitação do motorista e comportamento de decline recente.
3. Ring expander — se não existem motoristas elegíveis no ring interno, expande para fora em rings H3 concêntricos até que um set candidato se forme ou um limite max-distance seja atingido. A Uber publicou várias iterações dessa estratégia de expansão, incluindo expansão ML-driven que prediz trajetórias prováveis de motoristas.
4. Candidate ranker — pontua cada candidato em ETA-até-pickup, eficiência marketplace (queremos manter este motorista neste bairro?) e probabilidade histórica de aceitação para esse par passageiro/motorista.
5. Assignment solver — formula o problema de matching como otimização com restrições sobre o pool de oferta local. O solver roda continuamente, batchando solicitações próximas em vez de se comprometer com um greedy first-best-match.
6. Notification dispatcher — envia ao candidato matchado uma push notification com janela curta de aceitação. Registra aceitação/decline de volta em driver-state.
7. Path de fallback — em timeout do solver ou sem candidatos elegíveis, retry com restrições relaxadas (tipos de veículo mais amplos, ETA mais longo) ou escalação para surge.

O padrão é brutalmente simples uma vez visto: toda query espacial é um ring H3; toda decisão de negócio é um candidato pontuado; todo match é o output de um solver run global, não uma decisão local greedy. A forma elimina toda uma classe de anti-patterns "primeiro motorista pega a corrida" que assolam sistemas de dispatch ingênuos.

É assim que o C4 a nível de Componente parece: não "aqui está código", mas "aqui está a cadeia de primitivas significativas para o negócio, cada uma possuída, cada uma substituível, cada uma mensurável".

Funcionalidade Archyl em jogo. Diagramas Componente mostram como um container é construído. Cada componente tem um tipo (controller / service / repository / handler / module / job / workflow / activity / entity), um path de arquivo, owners e tecnologias. Componentes se compõem em um User Flow — a funcionalidade flow do Archyl permite autorar a jornada do passageiro como uma sequência ordenada de invocações de componentes e renderizá-la como diagrama passo-a-passo.

ADR-003 · Schemaless e Docstore — possua a camada de storage em vez de comprar

Status · Aceito (Schemaless: ~2014; Docstore: ~2020 em diante)

Contexto · Por volta de 2014, o volume de corridas da Uber havia ultrapassado uma única instância PostgreSQL, e as opções NoSQL off-the-shelf da época (Cassandra, Couchbase, MongoDB) tinham peculiaridades operacionais que a Uber não estava disposta a aceitar para dados de corrida e pagamento. Estado de corrida precisa de escritas multi-região fortemente consistentes, baixa latência p99 e sharding sem downtime. A resposta da indústria em 2014 era "escolha um NoSQL e conviva com os trade-offs".

Decisão · Tratar MySQL como bedrock durável e construir em cima. Schemaless envolve MySQL sharded com um log append-only sem triggers, re-sharding automático e uma API de documento JSON. Anos depois, Docstore sobrepõe um document store transacional multi-região fortemente consistente sobre o mesmo substrato MySQL — e se torna o default para novos dados de produto.

Consequências · A Uber ficou fora do ciclo boom-bust de "vamos migrar para NewSQL"/"vamos migrar de volta para Postgres" que atingiu várias empresas de tamanho similar. O caminho é incremental: novos workloads ganham Docstore; workloads maduros ficam em Schemaless até a migração. Ambos são operados por um pequeno time de plataforma com expertise profunda em MySQL. O rumor de que a Uber foi all-in em Cassandra? Eles usam Cassandra, mas nunca foi o sistema de registro para corridas.

Esse ADR é um ótimo exemplo de arquitetura path-dependent: em 2014, a resposta certa era estender MySQL, não migrar para fora dele.

Funcionalidade Archyl em jogo. A detecção de drift importa mais aqui. Quando um novo serviço começa a escrever em "Schemaless" mas o modelo C4 ainda diz "PostgreSQL", o Archyl calcula um drift score contra a codebase e o sinaliza semanalmente. ADRs previnem o próximo drift: um novo time escrevendo em um novo datastore teria que registrar um ADR propondo a mudança, que o time de plataforma pode aprovar ou rejeitar.

Três decisões. Três cards no Archyl, cada um ligado aos elementos C4 que molda — H3 a cada container espacial, Cadence a cada workflow de longa duração, Schemaless/Docstore à camada de dados. O diagrama é o presente; os ADRs são o porquê.

Ownership: transformar um modelo em accountability

Um modelo C4 é um artefato estático até que você mapeie times nele. A Uber comunica publicamente sobre sua estrutura de engenharia: fortes grupos Foundation (Storage, Compute, Networking, Observability, Security, ML Platform, Maps), orgs de produto alinhadas a Mobility, Delivery e Freight, e uma organização Marketplace central que possui o motor econômico cross-produto.

Coloque esses no modelo C4:

• Marketplace possui DISCO, o serviço de pricing dinâmico, surge, a plataforma ETA e os forecasters de demanda/oferta
• Mobility Engineering possui os apps de passageiro e motorista, o trip orchestrator, os flows de rating e tipping, o toolkit de safety
• Delivery Engineering possui a orquestração de pedidos do Eats, courier matching (que reusa primitivas DISCO), as ferramentas de mercador e as plataformas de menu/inventário
• Freight Engineering possui os workflows específicos de longa distância: load matching, ferramentas de broker, settlement
• Maps possui routing, modelos ETA, ingestão de tráfego, a biblioteca H3
• ML Platform (Michelangelo) possui o treinamento de modelos, feature stores, online serving e o stack de observability ML
• Storage Platform possui Schemaless, Docstore, Cassandra, o tooling de backup/restore
• Compute Platform possui o cluster manager era Kubernetes e os descendentes de Aurora/Peloton
• Observability possui M3 (metrics), Jaeger (tracing), o pipeline de logs
• Security & Identity possui Risk, IAM, a plataforma de secrets e os sinais abuse/fraude compartilhados com Marketplace
• Cadence/Workflow Platform possui o runtime de workflow durável usado por cada produto

Uma vez que um sistema, container ou componente tem um time owner, a detecção de drift se torna accountable. Quando um novo serviço aparece nos commits e não está no diagrama, um time específico recebe a pergunta. Quando uma regra de conformidade é violada — "apenas serviços Marketplace podem escrever no cache surge" — há um nome em uma caixa de entrada.

No Archyl, o Mapa de Ownership é o momento em que uma ferramenta de documentação se torna uma ferramenta de governança.

Funcionalidade Archyl em jogo. Cada elemento C4 suporta owners.teams e owners.users. A visão Mapa de Ownership consolida a cobertura para que você veja (e corrija) as caixas que ninguém possui. Gaps de cobertura são inaceitáveis em qualquer sistema desse tamanho — é como o on-call escala para um canal Slack onde ninguém responde.

Drift, conformidade e o problema dos quatro mil serviços

Um modelo com quatro mil microserviços vai sofrer drift. Forte. Mobility ship uma feature; um novo microserviço aparece; o contrato de dados do Marketplace evolui; um serviço deprecated de 2019 finalmente se aposenta. Multiplique isso por cada time, cada trimestre.

O Archyl calcula um drift score semanalmente: o gap entre o modelo C4 documentado e o que está atualmente na codebase. O número é limitado entre 0 e 100. Um drift score de 12 pode significar seis novos serviços ainda não no modelo, três relacionamentos no diagrama apontando para endpoints deletados e um punhado de containers tagueados com tecnologias que não correspondem mais ao stack real.

Regras de conformidade adicionam a camada de policy. Exemplos que uma org Marketplace pode escrever:

• Apenas serviços Marketplace podem ler do cache surge
• Cada container que manuseia PII deve carregar a tag pii:true e referenciar um ADR de Identity
• Todas as APIs públicas devem ter um contrato OpenAPI ou gRPC anexado — e esse contrato deve ser a source of truth, não a implementação
• Cada container precisa de um time owner
• Mutações de estado de corrida devem passar pelo Cadence; escritas diretas no banco são proibidas
• Novos datastores requerem um ADR e um sign-off do Storage Platform

O Archyl avalia essas regras continuamente. Violações aparecem no diagrama, no digest semanal do time e como checks em commit-time se você cabear a GitHub Action.

Funcionalidades Archyl em jogo.

• Drift score para o gap entre modelo e código, recalculado a cada push
• Regras de conformidade autoradas como YAML, aplicadas a todos os elementos C4
• Architecture Change Requests — review estilo pull-request para mudanças de modelo propostas, para que a arquitetura siga o mesmo rigor que o código
• Architecture Insights — anomalias e recomendações afloradas pela IA dos sinais drift + conformidade

Para um stack do tamanho da Uber, isso não é opcional. É a única forma do modelo permanecer honesto sem um time dedicado de documentação de arquitetura.

Contratos de API, eventos e o sistema nervoso do marketplace

O Marketplace na Uber é um grafo de serviços trocando eventos em alta velocidade. Transições de estado de corrida, atualizações de localização do motorista, recálculos de surge, quotes de tarifa, autorizações de pagamento — cada mudança emite um evento Kafka consumido por zero-a-muitos serviços downstream. A maioria das chamadas síncronas serviço-a-serviço são gRPC.

No Archyl:

• Cada container pode ter um contrato de API anexado (HTTP/OpenAPI, gRPC, GraphQL ou AsyncAPI). A spec é renderizada inline; consumidores veem exatamente o que estão chamando.
• Cada canal async pode ser modelado como um Event Channel com broker (Kafka), nome de topic, formato de schema (Avro, Protobuf, JSON Schema) e o body do schema. Producers e consumers são linkados ao canal.
• Mudanças breaking aparecem como um diff no contrato — e se você tem regras de conformidade exigindo um version bump, a mudança é bloqueada até a regra ser satisfeita.

Para a Uber, são três mil topics e dezenas de milhares de contratos se tornando inspecionáveis do mesmo lugar que o modelo C4. Sem mais "quem consome meus eventos?" — o modelo sabe.

DORA na escala Marketplace

Uma vez que você tem elementos C4 com owners, pode conectá-los à telemetria de delivery. O módulo DORA do Archyl puxa frequência de deploy, lead time de mudanças, taxa de falha de mudanças e tempo médio de recuperação dos seus sistemas CI/CD e de incidentes — e os consolida por elemento C4 e por time.

Para o Trip Orchestrator de Mobility, você veria a cadência de deploy e estabilidade desse time separadamente de Pricing. Para Marketplace no geral, você veria como o MTTR da plataforma toda está tendendo. Quando o MTTR pica, drilla nos containers culpados; quando a frequência de deploy estagna, você pode atribuí-la a uma sub-árvore específica.

Funcionalidade Archyl em jogo. O dashboard DORA no Archyl renderiza as quatro métricas com breakdowns por time e elemento e linhas de tendência, e amarra incidentes aos elementos de arquitetura que afetaram. É como "temos observability" se torna "temos saúde de engenharia".

E então tem a camada IA

Um stack de 4.000 serviços é o habitat natural para agentes de coding IA — Claude Code, Cursor, Windsurf e o resto. Cada engenheiro da Uber tem o mesmo problema: "como o serviço X conversa com o serviço Y, e onde o multiplicador de surge é realmente persistido?"

No Archyl, o modelo é exposto via um servidor MCP. Qualquer agente IA no laptop de um engenheiro pode perguntar:

• "Liste todos os serviços que dependem da biblioteca H3"
• "Mostre o contrato de API para dispatch.MatchService"
• "Quais ADRs cobrem decisões de storage?"
• "Gere um plano de migração de Cadence para Temporal SDK v2 entre os serviços possuídos"

O agente recebe o mesmo contexto arquitetural que um engenheiro recebe. Onboarding diminui. Code reviews cross-time param de ser "o que isso faz mesmo?". O contexto que vivia em cabeças agora vive em um modelo consultável.

Funcionalidades Archyl em jogo. Servidor MCP para agentes IA, import/export em YAML archyl, Structurizr DSL, LikeC4, IcePanel JSON e formato catálogo Backstage — para que dados de arquitetura existentes fluam sem um rewrite. Documentação de projeto, user flows e architecture insights completam a superfície.

A superfície completa de funcionalidades para uma organização nessa escala

Se você é uma org de engenharia formato-Uber avaliando o Archyl, aqui está a superfície, mapeada para as partes do seu dia-a-dia onde ela ganha seu lugar:

• Modelo C4 com todos os quatro níveis — Contexto do Sistema, Container, Componente, Code — com auto-layout, overlays e navegação click-through. A coisa que toda ferramenta de diagramming acerta; nós acertamos e continuamos.
• Descoberta de arquitetura por IA — aponte o Archyl para um repositório e ele descobre elementos C4 automaticamente. Te leva de zero ao primeiro modelo em uma hora, não em um trimestre.
• Architecture-as-Code — archyl.yaml checked into git, parseado e validado. CI/CD-ready via GitHub Action. Mesmo rigor que o código.
• Import multi-formato — catálogo Backstage (JSON), Structurizr DSL, LikeC4, IcePanel JSON, mais o YAML nativo do Archyl.
• ADRs ligados a elementos C4 com ciclo de vida completo (proposed / accepted / deprecated / superseded).
• Documentação de projeto com markdown, anexos, ligando a elementos específicos — seu handbook de arquitetura vivo.
• Contratos de API para HTTP/gRPC/GraphQL/AsyncAPI, renderizados inline contra o container produtor.
• Event channels com broker, topic, schema, producers e consumers — o lado async da arquitetura.
• Releases & ambientes — deploys versionados ligados à arquitetura, expostos no diagrama.
• Mapa de Ownership com atribuições de time e usuário em cada nível.
• Drift score entre o modelo e a codebase real, recalculado a cada push.
• Regras de conformidade como policy no modelo — autorar, avaliar e aplicar.
• Architecture Change Requests — review estilo pull-request para mudanças de modelo propostas.
• Architecture Insights — anomalias, riscos e recomendações aflorados pela IA.
• Métricas DORA consolidadas por elemento e por time, com linhas de tendência e atribuição de incidentes.
• Architecture Team Digest — um resumo semanal por time escopado ao perímetro possuído do time.
• Integração MCP — cada agente de coding IA no time compartilha o mesmo contexto arquitetural.
• Reviews de PR GitHub — o bot de review do Archyl comenta em PRs que impactam arquitetura com contexto de drift, conformidade e ADR.
• Sharing & embedding — links públicos, links team-only, iframes embutíveis para wikis internos.
• Export de imagem/PDF — PNG, SVG e PDF para apresentações, docs formais e slides impressos.
• Multi-idioma — cada superfície do Archyl disponível em nove idiomas, incluindo os docs e os prompts de agente.

Essa é a caixa de ferramentas completa. Para um stack como a Uber, você usaria praticamente tudo. Para um stack de cinquenta serviços, você usaria a metade que combina com sua maturidade — e cresceria para o resto.

Você não precisa de quatro mil serviços

Você não é a Uber. A maioria das organizações de engenharia não é.

Mas a lição escala para baixo. A disciplina de separar Contexto de Container de Componente, de escrever o ADR que explica uma decisão path-dependent (construímos H3, construímos Cadence, estendemos MySQL em vez de substituir), de anexar ownership a cada caixa — essa disciplina é o que mantém um stack de cinquenta serviços de parecer quatro mil.

C4 + ADRs + Ownership + Drift + Conformidade + Contratos de API + DORA + MCP — é isso que o Archyl te dá out of the box. O exemplo da Uber é apenas o maior stress-test plausível do modelo no domínio marketplace-e-logística.

Abra sua própria arquitetura. Esboce dez produtos (ou três, se você tem três). Escolha aquele com as decisões passadas mais surpreendentes e dê zoom em seus containers. Escreva três ADRs explicando o que confundiria um novato. Mapeie um time para cada container.

Você estará à frente de onde a maioria das organizações de engenharia chega em um ano.

Quer modelar sua própria arquitetura em C4? Comece com Archyl. Leia mais sobre por que ADRs e C4 funcionam melhor juntos ou como Architecture Change Requests trazem o rigor de pull-request para seu modelo C4. Os estudos de caso anteriores modelaram Stripe em C4 — Anatomia de um Charge e Netflix em C4 — Anatomia de um Play.