Aviso. Este artículo se basa enteramente en las comunicaciones públicas de Uber — su blog de ingeniería, charlas de conferencias, repositorios open source y casos de estudio externos. No es un documento de arquitectura oficial de Uber. Modelamos lo que sabemos públicamente para ilustrar cómo un stack de cuatro mil servicios puede hacerse legible con el modelo C4. Donde los detalles son inferidos en lugar de declarados por Uber, lo decimos.

Anatomía de un viaje: modelando Uber en C4 con Archyl

Un pasajero toca Solicitar UberX a las 7:23 pm un viernes lluvioso en Manhattan. Ocho segundos después, un conductor a 0.4 millas ha aceptado el viaje, se ha calculado y mostrado un ETA, la tarifa está bloqueada, el pago está pre-autorizado y un canal en tiempo real de baja latencia está abierto entre pasajero y conductor. Para cuando él levanta la vista del teléfono, el carro ya está en camino hacia él.

Ese único toque, repetido más de 30 millones de veces al día en 600+ ciudades, atraviesa decenas de sistemas de Uber y tres redes externas antes de que el frame cero aterrice en la pantalla del conductor.

En 2024, el stack de Uber corría aproximadamente 4.000 microservicios, servía picos muy por encima de un millón de requests por segundo a sus clientes móviles, programaba compute en su propio cluster manager, persistía estado en su propia capa de storage derivada de MySQL, indexaba el planeta en su propia grilla hexagonal, orquestaba millones de workflows de viajes en su propio motor de máquinas de estado y entrenaba modelos de ETA en su propia plataforma ML.

¿Cómo entiendes un stack con tantas piezas móviles? Como Stripe y Netflix, no lo haces — no todo a la vez. Eso es exactamente el problema que el modelo C4 fue inventado para resolver.

En este post seguimos una sola acción de usuario — una solicitud de viaje desde el toque hasta la aceptación del conductor — y la observamos atravesar la arquitectura de Uber a través de los cuatro niveles C4. No cubriremos cada producto; rastrearemos un viaje, escribiremos los ADRs que explican las decisiones que encontramos en el camino, y terminaremos con un mapa de los equipos que poseen cada caja. En el camino, recorreremos cada característica que Archyl ofrece para hacer este tipo de modelo — y las políticas a su alrededor — realmente mantenible.

Nivel 1 — Contexto del Sistema: tres plataformas, un Marketplace

A nivel de Contexto del Sistema, Uber no es "una app de transporte". Son tres plataformas de producto sentadas sobre un Marketplace compartido y un stack de sistemas Foundation transversales:

1. Mobility — UberX, Uber Black, Uber Pool, Uber Reserve, Comfort, SUV, Premier, alianzas con taxis
2. Delivery — Uber Eats (comida), Uber Direct (delivery-as-a-service para terceros), Postmates, alcohol, supermercado
3. Freight — transporte de larga distancia, Uber Freight Loadbuilder, herramientas de broker

Debajo de ellos, la plataforma Marketplace es el verdadero cerebro — el motor de matching, el optimizador de dispatch, el sistema de pricing dinámico, los forecasters de oferta/demanda. Marketplace es lo que convierte una solicitud de viaje en un viaje.

Debajo de ellos están las plataformas Foundation: Maps (routing, ETA, matrices de distancia/duración, tráfico), Payments, Identity & Risk, Communications (push, SMS, mensajería in-app), Notifications, la plataforma ML (Michelangelo), el motor de Workflow (Cadence/Temporal), las plataformas de Storage (Schemaless, Docstore, Cassandra, stores basados en RocksDB), las plataformas de Streaming (Kafka, uReplicator, Flink), el stack de Observability (M3 metrics, Jaeger tracing, ELK logs) y la plataforma de Compute (históricamente Mesos + Aurora → Peloton → basado en Kubernetes hoy).

Alrededor de ellos, los actores externos: pasajeros, conductores, eaters, couriers, comerciantes, shippers y carriers, proveedores de mapas (los suyos + terceros para fallback), redes de pago y bancos adquirentes, proveedores de verificación de identidad, operadores de telecom para SMS y voz, proveedores cloud (Uber corre híbrido: data centers propios + AWS/GCP para workloads específicos) y reguladores a nivel ciudad.

Tres plataformas de producto. Un Marketplace. Diez plataformas Foundation. Todo lo demás es detalle.

Este es el regalo del Nivel 1: a Contexto del Sistema, no necesitas saber que Mobility son doscientos microservicios. Necesitas saber que existe, que habla con Marketplace, que Marketplace habla con Maps, y que Cadence orquesta el workflow de viaje largo debajo. El diagrama es un punto de partida para la conversación, no un inventario.

Característica de Archyl en juego. Un diagrama de Contexto del Sistema en Archyl es una vista única de C4 Nivel 1 con auto-layout, navegación click-through hacia containers y overlays que te permiten silenciar/destacar subconjuntos (p. ej. "mostrar solo plataformas Foundation"). Los actores externos son elementos C4 de primera clase con su propio tipo, así que se renderizan de forma distinta.

ADR-001 · Grilla hexagonal H3 para indexación geoespacial

Estado · Aceptado (2018, open-sourced; sigue activo en 2026)

Contexto · El motor de matching de Marketplace necesita responder "¿qué conductores están cerca de este pasajero?" en milisegundos, a concurrencia a escala de ciudad, mientras soporta analytics como zonas de surge, ETAs y forecasting de oferta. Las opciones clásicas eran teselados rectangulares (Z-order, geohash, celdas S2 de Google) pero los rectángulos tienen una falla fundamental para este dominio: cada rectángulo tiene más de una distancia de vecino — las esquinas están más lejos que los bordes, lo que produce aproximaciones de distancia desiguales y consultas asimétricas de "qué hay cerca".

Decisión · Teselar el planeta en hexágonos en su lugar. Construir una grilla hexagonal jerárquica (H3) con dieciséis resoluciones desde escala continental hasta ~1 m². Cada hexágono tiene seis vecinos equidistantes, haciendo que las consultas de vecino-más-cercano y ring sean simétricas y rápidas. Open-sourcear la biblioteca para que socios e ingenieros de Uber compartan la misma grilla.

Consecuencias · H3 se convirtió en la primitiva espacial de Uber a través de Marketplace, Maps, ETA, surge y analytics. El mismo H3Index se usa en hot paths de dispatch y en jobs offline de forecasting. También es uno de los proyectos open source más exitosos de Uber — usado por Foursquare, DoorDash, AT&T y countless geo-startups. Los pocos casos donde los hexágonos no teselan limpiamente (los 12 anclajes pentagonales del icosaedro) están documentados y evitados en código de producción.

En Archyl, así es como un ADR gana su lugar: explica por qué la frontera tiene la forma que tiene. Haz clic en cualquier container que toque estado geoespacial y el ADR de H3 está a un clic.

Característica de Archyl en juego. Los ADRs en Archyl son registros de primera clase enlazados a elementos C4 específicos. Aparecen como tarjetas en las cajas relevantes, son filtrables por estado (proposed, accepted, deprecated, superseded) y se envían a git como YAML para que vivan junto al código. Cuando alguien proponga reemplazar H3 en 2030, el ADR existente aparece automáticamente como contexto relacionado.

Nivel 2 — Container: zoom en el camino de dispatch del Marketplace

El toque del pasajero aterriza en el edge de la API. Abramos la caja.

El camino de dispatch atraviesa algo así como los siguientes containers:

• Edge gateway — históricamente TChannel + Thrift IDL, hoy un edge gRPC + HTTP/2 para clientes móviles. Hace auth, rate limiting, request shaping y routing.
• Trip orchestrator — corre como un workflow de Cadence/Temporal de larga duración. El viaje es una instancia de workflow con transiciones de estado deterministas: requested → matched → arriving → on-trip → completed. Reintentos idempotentes y escalaciones por timer son primitivas integradas, no código bespoke.
• Motor de matching (DISCO) — el optimizador real del marketplace. Dada una solicitud de pasajero y la oferta de conductores en vivo dentro de unas pocas distancias de ring H3, resuelve un problema de asignación restringido en cada tick.
• Servicio de pricing dinámico — combina señales en tiempo real de oferta/demanda para calcular multiplicadores de surge por celda H3. Saca un quote de tarifa que se bloquea al momento de la solicitud.
• Servicio ETA — alimenta Maps + modelos ML para ruta, tráfico y predicción de llegada. Los modelos ETA de Uber pasaron a deep learning hacia 2018 y se han refinado cada año desde entonces.
• Plataforma Maps — el motor de routing in-house de Uber, servicio de matriz de distancias y pipeline de ingestión de tráfico. Cae a proveedores de mapas externos en mercados selectos.
• Servicio de Driver state — rastrea el estado actual de cada conductor (offline, online, en viaje), ubicación y comportamiento de aceptación. Lecturas/escrituras en datos de ubicación hot-path vía geo-stores custom.
• Schemaless / Docstore — el storage MySQL sharded de Uber. Schemaless es el más antiguo; Docstore es el sucesor más nuevo, multi-región, transaccional. Estado de viaje, pagos, perfiles de usuario y la mayoría de los datos line-of-business viven aquí.
• Cluster Kafka — cada transición de estado emite un evento. Marketplace se suscribe para analytics; los servicios downstream se suscriben para fanout (notifications, fraude, contabilidad).
• Canal en tiempo real — una vez matcheado, un canal bidireccional de baja latencia entre las apps de pasajero y conductor para actualizaciones de ubicación y chat. Respaldado por gateways long-poll/WebSocket y Kafka debajo.

El stack tecnológico en este nivel: Go para la mayoría de los nuevos servicios de alto throughput, Java en código viejo de marketplace, Python en pipelines ML y scripts de ops, Node.js en algunas capas edge, gRPC como el protocolo RPC moderno (TChannel/Thrift fue el predecesor), Cassandra y Redis para latencia hot-path, MySQL debajo de Schemaless/Docstore, Hadoop/HDFS/Hive/Presto para el data warehouse, Spark/Flink para compute batch y streaming.

Una solicitud de viaje típica toca Edge gateway → Trip orchestrator (Cadence) → Motor de matching (DISCO con consultas de ring H3 contra Driver state) → Pricing dinámico → ETA → fanout de Notifications (push al conductor) → callback de driver-accept → canal en tiempo real establecido. Todo eso, con reintentos, instrumentado end-to-end vía Jaeger y medido vía M3.

Característica de Archyl en juego. Los diagramas a nivel Container muestran cada container, su tipo (api / service / database / message_queue / cache / worker / gateway / library / infrastructure), sus tecnologías (extraídas de un catálogo tecnológico por organización) y sus relaciones con etiquetas. Los contratos de API pueden adjuntarse a cualquier container y renderizarse inline — Uber enlazaría el .proto gRPC para la orquestación de viajes directamente al container del Trip orchestrator.

ADR-002 · Cadence (Temporal) — construir un motor de workflow, no apilar microservicios stateful

Estado · Aceptado (~2017, open-sourced como Cadence; spin-off como Temporal)

Contexto · Hacia 2017, Uber tenía cientos de microservicios implementando procesos de negocio de larga duración y stateful — viajes, pedidos, flows de signup, onboarding de conductores, revisiones de fraude. Cada uno había hecho crecer su propia máquina de estado ad-hoc con timers, reintentos, idempotencia y código de recuperación. Resultado: cada equipo pagaba el impuesto de sistemas distribuidos y los outages frecuentemente venían de bugs sutiles en lógica de retry/timeout.

Decisión · No pedirle a cada equipo que invente una máquina de estado. Construir un motor de workflow genérico con replay determinista, timers durables, reintentos automáticos, manejo de signals y un modelo de programación donde el código de workflow se lee como lógica de negocio secuencial. Open-sourcearlo como Cadence. Migrar viajes, signup, revisiones de fraude y workflows de movimiento de dinero allí a lo largo de varios años.

Consecuencias · Cadence (y su fork Temporal, ahora usado dentro y fuera de Uber) es ahora el sustrato para cada flow stateful de larga duración en Uber. La abstracción "el viaje es un workflow" colapsa miles de líneas de código bespoke de retry en un puñado de actividades bien tipadas. El motor también se convirtió en uno de los proyectos de workflow open source más adoptados en la industria. La lección path-dependent: cuando diez equipos están reimplementando independientemente la misma primitiva, construye la primitiva.

Característica de Archyl en juego. Decisiones como Cadence se propagan a través del modelo. En Archyl, un ADR puede enlazar múltiples elementos C4 simultáneamente — una decisión, muchas cajas afectadas. Buscar "workflow" a través del modelo destaca cada container anotado como consumidor de Cadence.

Nivel 3 — Componente: dentro del motor de matching

De todos los componentes en el stack de Uber, el motor de matching — internamente DISCO — es el mejor documentado en charlas de conferencias y posts de ingeniería.

Una solicitud de viaje, una vez que llega al motor de matching, atraviesa estos componentes:

1. Request normalizer — convierte las coordenadas del pasajero en un índice H3 en múltiples resoluciones (típicamente res 9 para hot-path, res 6 para expansión de ring).
2. Supply scanner — consulta el índice de driver-state en vivo para todos los conductores elegibles dentro de un ring H3 inicial (~500 m). Filtra por tipo de vehículo, tasa de aceptación del conductor y comportamiento reciente de decline.
3. Ring expander — si no existen conductores elegibles en el ring interior, expande hacia afuera en rings H3 concéntricos hasta que se forme un set candidato o se alcance una cota de max-distance. Uber ha publicado varias iteraciones de esta estrategia de expansión, incluyendo expansión ML-driven que predice trayectorias probables de conductores.
4. Candidate ranker — puntúa cada candidato en ETA-al-pickup, eficiencia de marketplace (¿queremos mantener este conductor en este vecindario?) y probabilidad histórica de aceptación para este par pasajero/conductor.
5. Assignment solver — formula el problema de matching como una optimización restringida sobre el pool de oferta local. El solver corre continuamente, batchando solicitudes cercanas en lugar de comprometerse con un greedy first-best-match.
6. Notification dispatcher — envía al candidato matcheado una notificación push con una ventana de aceptación corta. Registra aceptación/decline de vuelta en driver-state.
7. Path de fallback — en timeout del solver o sin candidatos elegibles, retry con restricciones relajadas (tipos de vehículo más amplios, ETA más largo) o escalación a surge.

El patrón es brutalmente simple una vez que lo ves: cada consulta espacial es un ring H3; cada decisión de negocio es un candidato puntuado; cada match es el output de un solver global, no una decisión local greedy. La forma elimina toda una clase de anti-patterns "el primer conductor agarra la tarifa" que plagan los sistemas de dispatch ingenuos.

Esto es como se ve C4 a nivel Componente: no "aquí hay código", sino "aquí está la cadena de primitivas significativas para el negocio, cada una con dueño, cada una reemplazable, cada una medible".

Característica de Archyl en juego. Los diagramas Componente muestran cómo está construido un container. Cada componente tiene un tipo (controller / service / repository / handler / module / job / workflow / activity / entity), un path de archivo, owners y tecnologías. Los componentes se componen en un User Flow — la característica de flow de Archyl te permite autorear el viaje del pasajero como una secuencia ordenada de invocaciones de componentes y renderizarlo como un diagrama paso a paso.

ADR-003 · Schemaless y Docstore — poseer la capa de storage en lugar de comprar

Estado · Aceptado (Schemaless: ~2014; Docstore: ~2020 en adelante)

Contexto · Hacia 2014, el volumen de viajes de Uber había superado una sola instancia PostgreSQL, y las opciones NoSQL off-the-shelf de la época (Cassandra, Couchbase, MongoDB) tenían rarezas operacionales que Uber no estaba dispuesto a aceptar para datos de viajes y pagos. El estado de viaje necesita escrituras multi-región fuertemente consistentes, baja latencia p99 y sharding sin downtime. La respuesta de la industria en 2014 era "elige un NoSQL y vive con los trade-offs".

Decisión · Tratar a MySQL como el bedrock durable y construir encima. Schemaless envuelve MySQL sharded con un log append-only sin triggers, re-sharding automático y una API de documento JSON. Años después, Docstore superpone un store de documentos transaccional multi-región fuertemente consistente sobre el mismo sustrato MySQL — y se convierte en el default para nuevos datos de producto.

Consecuencias · Uber se ha mantenido fuera del ciclo de boom-bust de "vamos a migrar a NewSQL"/"vamos a migrar de vuelta a Postgres" que golpeó a varias compañías de tamaño similar. El path es incremental: nuevos workloads obtienen Docstore; workloads maduros se quedan en Schemaless hasta migrar. Ambos son operados por un pequeño equipo de plataforma con expertise profundo en MySQL. ¿El rumor de que Uber se fue all-in en Cassandra? Usan Cassandra, pero nunca ha sido el sistema de registro para viajes.

Este ADR es un gran ejemplo de arquitectura path-dependent: en 2014, la respuesta correcta era extender MySQL, no migrar fuera de él.

Característica de Archyl en juego. La detección de drift importa más aquí. Cuando un nuevo servicio comienza a escribir en "Schemaless" pero el modelo C4 todavía dice "PostgreSQL", Archyl calcula un drift score contra la codebase y lo señala semanalmente. Los ADRs previenen el próximo drift: un nuevo equipo escribiendo en un nuevo datastore tendría que presentar un ADR proponiendo el cambio, que el equipo de plataforma puede aprobar o rechazar.

Tres decisiones. Tres tarjetas en Archyl, cada una enlazada a los elementos C4 que da forma — H3 a cada container espacial, Cadence a cada workflow de larga duración, Schemaless/Docstore a la capa de datos. El diagrama es el presente; los ADRs son el porqué.

Ownership: convertir un modelo en accountability

Un modelo C4 es un artefacto estático hasta que mapeas equipos a él. Uber comunica públicamente sobre su estructura de ingeniería: fuertes grupos Foundation (Storage, Compute, Networking, Observability, Security, ML Platform, Maps), orgs de producto alineadas con Mobility, Delivery y Freight, y una organización Marketplace central que posee el motor económico cross-producto.

Coloca estos sobre el modelo C4:

• Marketplace posee DISCO, el servicio de pricing dinámico, surge, la plataforma ETA y los forecasters de demanda/oferta
• Mobility Engineering posee las apps de pasajero y conductor, el trip orchestrator, los flows de rating y tipping, el toolkit de safety
• Delivery Engineering posee la orquestación de pedidos de Eats, el matching de couriers (que reusa primitivas de DISCO), las herramientas de comerciante y las plataformas de menú/inventario
• Freight Engineering posee los workflows específicos de larga distancia: load matching, herramientas de broker, settlement
• Maps posee routing, modelos ETA, ingestión de tráfico, la biblioteca H3
• ML Platform (Michelangelo) posee el entrenamiento de modelos, feature stores, online serving y el stack de observability ML
• Storage Platform posee Schemaless, Docstore, Cassandra, el tooling de backup/restore
• Compute Platform posee el cluster manager era Kubernetes y los descendientes de Aurora/Peloton
• Observability posee M3 (metrics), Jaeger (tracing), el pipeline de logs
• Security & Identity posee Risk, IAM, la plataforma de secrets y las señales de abuse/fraude compartidas con Marketplace
• Cadence/Workflow Platform posee el runtime de workflow durable usado por cada producto

Una vez que un sistema, container o componente tiene un equipo dueño, la detección de drift se vuelve accountable. Cuando un nuevo servicio aparece en commits y no está en el diagrama, un equipo específico recibe la pregunta. Cuando una regla de conformidad es violada — "solo los servicios Marketplace pueden escribir al cache surge" — hay un nombre en una bandeja de entrada.

En Archyl, el Mapa de Ownership es el momento en que una herramienta de documentación se convierte en una herramienta de gobernanza.

Característica de Archyl en juego. Cada elemento C4 soporta owners.teams y owners.users. La vista Mapa de Ownership consolida la cobertura para que veas (y arregles) las cajas que nadie posee. Los gaps de cobertura son inaceptables en cualquier sistema de este tamaño — así es como on-call escala a un canal de Slack donde nadie responde.

Drift, conformidad y el problema de los cuatro mil servicios

Un modelo con cuatro mil microservicios va a derivar. Fuerte. Mobility envía una feature; aparece un nuevo microservicio; el contrato de datos de Marketplace evoluciona; un servicio deprecated de 2019 finalmente se retira. Multiplica eso por cada equipo, cada trimestre.

Archyl calcula un drift score semanalmente: la brecha entre el modelo C4 documentado y lo que actualmente está en la codebase. El número está acotado entre 0 y 100. Un drift score de 12 podría significar seis nuevos servicios aún no en el modelo, tres relaciones en el diagrama apuntando a endpoints eliminados y un puñado de containers etiquetados con tecnologías que ya no coinciden con el stack real.

Las reglas de conformidad añaden la capa de policy. Ejemplos que una org de Marketplace podría escribir:

• Solo los servicios Marketplace pueden leer del cache surge
• Cada container que maneja PII debe llevar el tag pii:true y referenciar un ADR de Identity
• Todas las APIs públicas deben tener un contrato OpenAPI o gRPC adjunto — y ese contrato debe ser la source of truth, no la implementación
• Cada container necesita un equipo dueño
• Las mutaciones de estado de viaje deben pasar por Cadence; las escrituras directas de base de datos están prohibidas
• Los nuevos datastores requieren un ADR y un sign-off de Storage Platform

Archyl evalúa estas reglas continuamente. Las violaciones se exponen en el diagrama, en el digest semanal del equipo y como checks en commit-time si conectas el GitHub Action.

Características de Archyl en juego.

• Drift score para la brecha entre modelo y código, recalculado en cada push
• Reglas de conformidad autoradas como YAML, aplicadas a todos los elementos C4
• Architecture Change Requests — review estilo pull-request para cambios de modelo propuestos, para que la arquitectura siga el mismo rigor que el código
• Architecture Insights — anomalías y recomendaciones afloradas por IA desde las señales de drift + conformidad

Para un stack del tamaño de Uber, esto no es opcional. Es la única forma en que el modelo se mantiene honesto sin un equipo dedicado de documentación de arquitectura.

Contratos de API, eventos y el sistema nervioso del marketplace

El Marketplace en Uber es un grafo de servicios intercambiando eventos a alta velocidad. Transiciones de estado de viaje, actualizaciones de ubicación de conductor, recálculos de surge, quotes de tarifas, autorizaciones de pago — cada cambio emite un evento Kafka consumido por cero a muchos servicios downstream. La mayoría de las llamadas síncronas servicio-a-servicio son gRPC.

En Archyl:

• Cada container puede tener un contrato de API adjunto (HTTP/OpenAPI, gRPC, GraphQL o AsyncAPI). La spec se renderiza inline; los consumidores ven exactamente lo que están llamando.
• Cada canal asíncrono puede modelarse como un Event Channel con broker (Kafka), nombre de topic, formato de schema (Avro, Protobuf, JSON Schema) y el cuerpo del schema. Productores y consumidores están enlazados al canal.
• Los cambios breaking aparecen como un diff en el contrato — y si tienes reglas de conformidad requiriendo un version bump, el cambio se bloquea hasta que la regla se satisfaga.

Para Uber, eso son tres mil topics y decenas de miles de contratos volviéndose inspeccionables desde el mismo lugar que el modelo C4. No más "¿quién consume mis eventos?" — el modelo lo sabe.

DORA a la escala de Marketplace

Una vez que tienes elementos C4 con dueños, puedes conectarlos a la telemetría de delivery. El módulo DORA de Archyl extrae frecuencia de despliegue, lead time de cambios, tasa de fallo de cambios y tiempo medio de recuperación de tus sistemas CI/CD e incidentes — y los consolida por elemento C4 y por equipo.

Para el Trip Orchestrator de Mobility, verías la cadencia de despliegue y estabilidad de ese equipo separadamente de Pricing. Para Marketplace en general, verías cómo está tendiendo el MTTR de toda la plataforma. Cuando el MTTR se dispara, profundiza en los containers ofensores; cuando la frecuencia de despliegue se estanca, puedes atribuirla a un subárbol específico.

Característica de Archyl en juego. El dashboard DORA en Archyl renderiza las cuatro métricas con desgloses de equipo y elemento y líneas de tendencia, y vincula incidentes con los elementos de arquitectura que afectaron. Es como "tenemos observability" se vuelve "tenemos salud de ingeniería".

Y luego está la capa IA

Un stack de 4.000 servicios es el hábitat natural para los agentes de coding IA — Claude Code, Cursor, Windsurf, y el resto. Cada ingeniero de Uber tiene el mismo problema: "¿cómo habla el servicio X con el servicio Y, y dónde se persiste realmente el multiplicador de surge?"

En Archyl, el modelo se expone vía un servidor MCP. Cualquier agente IA en la laptop de un ingeniero puede preguntar:

• "Lista todos los servicios que dependen de la biblioteca H3"
• "Muéstrame el contrato de API para dispatch.MatchService"
• "¿Qué ADRs cubren decisiones de storage?"
• "Genera un plan de migración de Cadence a Temporal SDK v2 a través de servicios poseídos"

El agente obtiene el mismo contexto arquitectónico que un ingeniero. El onboarding se reduce. Las code reviews cross-equipo dejan de ser "¿qué hace esto siquiera?". El contexto que vivía en cabezas ahora vive en un modelo consultable.

Características de Archyl en juego. Servidor MCP para agentes IA, import/export en YAML archyl, Structurizr DSL, LikeC4, IcePanel JSON y formato catálogo Backstage — para que los datos de arquitectura existentes fluyan sin un rewrite. Documentación de proyecto, user flows y architecture insights redondean la superficie.

La superficie completa de características para una organización a esta escala

Si eres una org de ingeniería con forma de Uber evaluando Archyl, aquí está la superficie, mapeada a las partes de tu día a día donde se gana su lugar:

• Modelo C4 con los cuatro niveles — Contexto del Sistema, Container, Componente, Code — con auto-layout, overlays y navegación click-through. Lo que toda herramienta de diagramming hace bien; lo hacemos bien y seguimos adelante.
• Descubrimiento de arquitectura por IA — apunta Archyl a un repositorio y descubre elementos C4 automáticamente. Te lleva de cero al primer modelo en una hora, no un trimestre.
• Architecture-as-Code — archyl.yaml checkeado en git, parseado y validado. CI/CD-ready vía GitHub Action. Mismo rigor que el código.
• Import multi-formato — catálogo Backstage (JSON), Structurizr DSL, LikeC4, IcePanel JSON, más el YAML nativo de Archyl.
• ADRs enlazados a elementos C4 con ciclo de vida completo (proposed / accepted / deprecated / superseded).
• Documentación de proyecto con markdown, attachments, enlazando a elementos específicos — tu handbook de arquitectura vivo.
• Contratos de API para HTTP/gRPC/GraphQL/AsyncAPI, renderizados inline contra el container productor.
• Event channels con broker, topic, schema, productores y consumidores — el lado asíncrono de la arquitectura.
• Releases & ambientes — despliegues versionados atados a la arquitectura, expuestos en el diagrama.
• Mapa de Ownership con asignaciones de equipo y usuario en cada nivel.
• Drift score entre el modelo y la codebase real, recalculado en cada push.
• Reglas de conformidad como policy en el modelo — autorear, evaluar y aplicar.
• Architecture Change Requests — review estilo pull-request para cambios de modelo propuestos.
• Architecture Insights — anomalías, riesgos y recomendaciones afloradas por IA.
• Métricas DORA consolidadas por elemento y por equipo, con líneas de tendencia y atribución de incidentes.
• Architecture Team Digest — un resumen semanal por equipo limitado al perímetro poseído del equipo.
• Integración MCP — cada agente de coding IA en el equipo comparte el mismo contexto arquitectónico.
• Reviews de PR de GitHub — el bot de review de Archyl comenta en PRs que impactan arquitectura con contexto de drift, conformidad y ADR.
• Sharing & embedding — enlaces públicos, enlaces team-only, iframes embebibles para wikis internos.
• Export de imagen/PDF — PNG, SVG y PDF para presentaciones, docs formales y diapositivas impresas.
• Multi-idioma — cada superficie de Archyl disponible en nueve idiomas, incluyendo los docs y los prompts de agente.

Esa es la caja de herramientas completa. Para un stack como el de Uber, usarías aproximadamente todo. Para un stack de cincuenta servicios, usarías la mitad que coincide con tu madurez — y crecerías hacia el resto.

No necesitas cuatro mil servicios

No eres Uber. La mayoría de las organizaciones de ingeniería no lo son.

Pero la lección escala hacia abajo. La disciplina de separar Contexto de Container de Componente, de escribir el ADR que explica una decisión path-dependent (construimos H3, construimos Cadence, extendimos MySQL en lugar de reemplazarlo), de adjuntar ownership a cada caja — esa disciplina es lo que mantiene un stack de cincuenta servicios sin sentirse como cuatro mil.

C4 + ADRs + Ownership + Drift + Conformidad + Contratos de API + DORA + MCP — eso es lo que Archyl te da out of the box. El ejemplo de Uber es solo el mayor stress-test plausible del modelo en el dominio marketplace-y-logística.

Abre tu propia arquitectura. Esboza diez productos (o tres, si tienes tres). Elige el de las decisiones pasadas más sorprendentes y haz zoom en sus containers. Escribe tres ADRs explicando lo que confundiría a un nuevo contratado. Mapea un equipo a cada container.

Estarás adelante de donde la mayoría de las organizaciones de ingeniería llegan en un año.

¿Quieres modelar tu propia arquitectura en C4? Comienza con Archyl. Lee más sobre por qué los ADRs y C4 funcionan mejor juntos o cómo los Architecture Change Requests llevan el rigor de pull-request a tu modelo C4. Los casos de estudio anteriores modelaron Stripe en C4 — Anatomía de un Cargo y Netflix en C4 — Anatomía de un Play.