Ejemplos de modelo C4: Stripe, Netflix, Uber y Revolut

La mayoría de los ejemplos de modelo C4 que se encuentran son un único sistema de juguete: un banco, una tienda online, una app de banca por internet con tres cajas y una base de datos. Muestran la notación. No muestran la parte difícil, que es decidir qué dejar fuera cuando el sistema real tiene cientos de servicios.

Esta página reúne cuatro ejemplos de modelo C4 más grandes, cada uno modelado desde el contexto hasta los componentes: un cobro con tarjeta en Stripe, una solicitud de reproducción en Netflix, una solicitud de viaje en Uber y una transferencia internacional en Revolut. Cada uno incluye su diagrama de nivel 1, un breve resumen de cómo hace zoom a los niveles 2 y 3 y un enlace al artículo completo. Al final hay un ejemplo pequeño que puedes copiar y una lista de lo que tienen en común los cuatro.

Una nota sobre las fuentes. Los cuatro ejemplos proceden de nuestra serie «Anatomy of», y cada uno se basa por completo en la comunicación pública de la empresa: blogs de ingeniería, charlas en conferencias, repositorios de código abierto, ofertas de empleo y casos de estudio externos. Ninguno es un documento de arquitectura oficial de la empresa en cuestión. Cada artículo completo indica dónde los detalles se deducen en lugar de ser afirmados por la empresa.

Si el modelo C4 es nuevo para ti, lee primero qué es el modelo C4. Las cuatro guías por nivel profundizan en cada tipo de diagrama: contexto de sistema, contenedores, componentes y código.

Qué hace bueno a un ejemplo C4

Un ejemplo de diagrama C4 es útil cuando puedes aprender una decisión de él, no solo una forma. Los cuatro de abajo se escribieron con las mismas reglas, y merece la pena adoptarlas antes de mirar cualquiera de ellos.

Sigue una sola acción del usuario. Ninguno de estos ejemplos intenta documentar la empresa entera. Cada uno elige una sola cosa que hace un usuario (un cobro, una reproducción, un viaje, una transferencia) y solo dibuja lo que esa acción toca. Eso es lo que reduce un parque de mil servicios a una página legible.

Limita el nivel 1 a unas diez cajas. En el nivel System Context, una empresa como Netflix no son mil microservicios. Son un puñado de sistemas de producto y los actores externos que los rodean. Si tu diagrama de nivel 1 necesita cuarenta cajas, los límites están trazados a la altura equivocada.

Haz zoom en un solo camino en el nivel 2. El diagrama de contenedores muestra los contenedores en el camino de esa única acción, con tecnologías y protocolos. No muestra todos los contenedores que opera la empresa.

Elige el zoom del nivel 3 por una razón. Solo un contenedor recibe un diagrama de componentes, y es aquel donde está la ingeniería interesante, o el que la empresa ha documentado públicamente con suficiente profundidad para modelarlo con honestidad.

Explica las cajas con decisiones. Cada ejemplo incluye tres breves architecture decision records entre niveles. Un diagrama muestra lo que existe. El ADR explica por qué es así, que es lo primero que pregunta alguien recién incorporado.

Así se comparan los cuatro de un vistazo:

Ejemplo 1: Stripe, un cobro con tarjeta

Basado en la comunicación pública de Stripe. No es un documento de arquitectura oficial de Stripe.

Nivel 1. En el nivel System Context, Stripe no es «una API de pagos». Nuestro modelo muestra quince sistemas de producto que comparten una base común: Payments, Connect, Billing, Radar, Issuing, Treasury y los demás. Alrededor están los comercios, los titulares de tarjetas, las redes de tarjetas, los métodos de pago alternativos, los bancos adquirentes y emisores, los socios bancarios y AWS.

Nivel 2. El diagrama de contenedores abre la caja Payments y sigue una llamada PaymentIntents.create(): el API gateway, una capa de idempotencia delante de cada endpoint que modifica datos, la máquina de estados del PaymentIntent, una bóveda de datos de tarjeta, el scoring de Radar en paralelo, los conectores con las redes, el libro contable y la entrega de webhooks.

Nivel 3. El zoom de componentes entra en la capa de idempotencia, porque es la parte de la stack mejor documentada públicamente: un hasher de peticiones, un almacén de claves en PostgreSQL, un ejecutor de fases y un rastreador de puntos de recuperación que permite a una petición reintentada continuar donde se detuvo.

Qué aprender de él. Es el ejemplo que hay que estudiar para los diagramas de componentes. La vista de nivel 3 no es una lista de clases; es una cadena de pasos sobre la que un lector puede razonar («cada efecto secundario externo queda entre dos puntos de recuperación»).

Artículo completo: Anatomy of a Charge: modelar Stripe en C4.

Ejemplo 2: Netflix, una solicitud de reproducción

Basado en la comunicación pública de Netflix. No es un documento de arquitectura oficial de Netflix.

Nivel 1. Diez sistemas aparecen de forma constante en el material público de Netflix: Member Experience, Content Discovery, Streaming Platform, Open Connect, Studio Engineering, Content Engineering, Data Platform, Cloud Platform, Security y la Ads Platform. Entre los actores externos están los dispositivos de los suscriptores, los ISP que alojan appliances de Open Connect, AWS, los proveedores de DRM, los socios de pago y los estudios de contenido.

Nivel 2. El zoom de contenedores abre la Streaming Platform y sigue una solicitud de reproducción: la Playback API, el servicio de manifiestos, el servicio de licencias para el DRM, la capa de seguridad de mensajes, un nivel de EVCache y los clústeres de Cassandra que hay detrás. El manifiesto dirige el dispositivo a un appliance de Open Connect, que es donde vuelve a aparecer la decisión de nivel 1 de construir una CDN.

Nivel 3. La vista de componentes entra en Cosmos, el pipeline de codificación de vídeo. No está en el camino de reproducción en el momento de la petición (la codificación ocurre cuando se ingesta un título), y el artículo lo dice. Se eligió porque Netflix ha publicado lo suficiente como para nombrar cada paso: inspección, análisis de complejidad, generación de la escalera de codificación, codificación, validación y puntuación de calidad.

Qué aprender de él. La demostración más clara de «diez cosas, no mil» en el nivel 1, y un buen ejemplo de cómo admitir que el zoom del nivel 3 sale del camino seguido.

Artículo completo: Anatomy of a Play: modelar Netflix en C4.

Ejemplo 3: Uber, una solicitud de viaje

Basado en la comunicación pública de Uber. No es un documento de arquitectura oficial de Uber.

Nivel 1. Uber en el nivel System Context son tres plataformas de producto (Mobility, Delivery, Freight) sobre un Marketplace compartido, con una capa de plataformas Foundation debajo: Maps, Payments, identidad y riesgo, comunicaciones, la plataforma de ML, el motor de workflows, almacenamiento, streaming, observabilidad y compute. Entre los actores externos están pasajeros, conductores, clientes de comida a domicilio, repartidores, comercios, redes de pago, operadores de telecomunicaciones y reguladores municipales.

Nivel 2. El zoom de contenedores sigue una solicitud de viaje por el camino de asignación del Marketplace: el edge gateway, un orquestador de viajes que ejecuta cada viaje como una instancia de workflow, el motor de emparejamiento, la tarificación dinámica, el servicio de ETA, el estado de los conductores, la capa de almacenamiento y Kafka.

Nivel 3. La vista de componentes abre el motor de emparejamiento: un normalizador de peticiones que convierte coordenadas en índices de hexágonos H3, un escáner de oferta, un expansor de anillos, un clasificador de candidatos, un solucionador de asignaciones, el despachador de notificaciones y un camino alternativo.

Qué aprender de él. El ejemplo de cómo dibujar una empresa de plataforma en el nivel 1 sin dibujar cada producto. El Marketplace compartido en el centro dice más sobre la arquitectura de Uber que cualquier lista de servicios.

Artículo completo: Anatomy of a Ride: modelar Uber en C4.

Ejemplo 4: Revolut, una transferencia internacional

Basado en la comunicación pública de Revolut. No es un documento de arquitectura oficial de Revolut.

Nivel 1. La comunicación pública describe al menos ocho sistemas de producto: Retail Banking, Business Banking, FX, Wealth y Trading, Credit, FinCrime, Onboarding y KYC, y el libro contable central con su backbone de eventos. A su alrededor: redes de tarjetas, sistemas de pago (Faster Payments, SEPA, SWIFT), bancos socios, reguladores y Google Cloud. El diagrama deja claro algo que un organigrama no mostraría: FinCrime recibe flechas de todos los productos, así que está en el camino crítico de todos ellos.

Nivel 2. El zoom de contenedores sigue una transferencia de EUR a GBP por Retail Banking: las apps móviles, el edge de la API, un orquestador de transferencias con una máquina de estados explícita, un libro contable de partida doble en PostgreSQL, el motor de FX, el pipeline de FinCrime, un conector por sistema de pago, el event store y las notificaciones.

Nivel 3. La vista de componentes abre Sherlock, el motor antifraude: ensamblado de features, un almacén de perfiles en memoria, el servidor de modelos, una política de decisión, el reentrenamiento nocturno y un bucle de retroalimentación de los analistas.

Qué aprender de él. Es el más completo de los cuatro ejemplos. Añade una cronología paso a paso entre los niveles 1 y 2 (con latencias marcadas claramente como ilustrativas, no publicadas) y una sección de «qué copiar y qué no» que dice qué decisiones debería copiar un equipo de diez servicios y cuáles no.

Artículo completo: Anatomy of a Transfer: modelar Revolut en C4.

Un ejemplo pequeño para copiar

Los cuatro ejemplos anteriores son grandes a propósito. La mayoría de los sistemas no lo son, así que aquí tienes un pequeño ejemplo de modelo C4 en los tres niveles útiles: la plataforma de e-commerce que usamos a lo largo de nuestra guía completa del modelo C4. Copia la forma y cambia los nombres de las cajas.

Nivel 1: System Context

[Cliente] --> [Plataforma de e-commerce] : Explora productos, realiza pedidos
[Personal de almacén] --> [Plataforma de e-commerce] : Gestiona el inventario
[Plataforma de e-commerce] --> [Payment Gateway (Stripe)] : Procesa pagos
[Plataforma de e-commerce] --> [Proveedor de envíos (FedEx API)] : Crea envíos
[Plataforma de e-commerce] --> [Email Service (SendGrid)] : Envía notificaciones

Dos tipos de usuario, tres sistemas externos y una caja para todo lo que es tuyo.

Nivel 2: Container

[Single-Page Application (React)] --> [API Gateway (Kong)] : Llama a la API (HTTPS/JSON)
[API Gateway] --> [Order Service (Go)] : Enruta las peticiones
[API Gateway] --> [Product Service (Go)] : Enruta las peticiones
[API Gateway] --> [User Service (Go)] : Enruta las peticiones
[Order Service] --> [Order Database (PostgreSQL)] : Lee/escribe pedidos
[Product Service] --> [Product Database (PostgreSQL)] : Lee/escribe productos
[User Service] --> [User Database (PostgreSQL)] : Lee/escribe usuarios
[Order Service] --> [Message Queue (Kafka)] : Publica eventos de pedido
[Notification Service (Go)] --> [Message Queue] : Consume eventos de pedido

Cada caja nombra su tecnología, cada flecha nombra su protocolo o su propósito, y los almacenes de datos se dibujan como contenedores.

Nivel 3: Component (dentro del Order Service)

[Order Handler] --> [Order Service] : Delega la lógica de negocio
[Order Service] --> [Order Repository] : Persiste los pedidos
[Order Service] --> [Payment Client] : Valida el pago
[Order Service] --> [Inventory Client] : Comprueba la disponibilidad de stock
[Order Repository] --> [Order Database (PostgreSQL)] : Consultas SQL
[Payment Client] --> [Payment Gateway (Stripe)] : HTTPS/REST
[Inventory Client] --> [Product Service] : gRPC

Solo un contenedor recibe un diagrama de componentes, la misma regla que siguen los cuatro grandes ejemplos. Los servicios Product y User son CRUD sencillo, así que dibujar su interior no añadiría nada que no muestre ya un listado de carpetas.

Para el razonamiento detrás de cada una de estas decisiones, consulta las guías por nivel: qué va en un diagrama de contexto de sistema, qué va en un diagrama de contenedores y cuándo merece la pena dibujar un diagrama de componentes. Aquí nos saltamos el nivel 4 por la misma razón que la mayoría de los equipos; la guía del diagrama de código explica cuándo se gana su sitio.

Qué tienen en común los cuatro

Puestos uno al lado del otro, los cuatro ejemplos siguen el mismo puñado de hábitos. Ninguno es una regla del propio modelo C4. Son lo que hizo legibles estos modelos.

Unas diez cajas en el nivel 1. Quince para Stripe, diez para Netflix, ocho para Revolut, y para Uber tres plataformas de producto sobre un Marketplace con las plataformas Foundation debajo. Ninguna de estas empresas es pequeña. Los diagramas de nivel 1 se mantienen pequeños porque agrupan por sistema de producto, no por servicio.

Un solo camino en el nivel 2. Cada diagrama de contenedores muestra solo los contenedores por los que pasa una acción. La vista de contenedores de Stripe no tiene contenedores de Billing ni de Atlas. La de Netflix no tiene nada de Studio Engineering. No es una omisión; esos contenedores pertenecen a otro diagrama, para otra acción.

Un solo contenedor en el nivel 3, elegido con honestidad. El zoom de componentes siempre va donde la documentación pública es lo bastante profunda como para dibujar componentes reales. El artículo de Netflix dice abiertamente que Cosmos está fuera del camino de reproducción en el momento de la petición. Un ejemplo que oculta ese tipo de elección enseña la lección equivocada.

Los sistemas externos pesan tanto como los internos. Redes de tarjetas, ISP, sistemas de pago, operadores de telecomunicaciones: en los cuatro ejemplos, algunas de las cajas más importantes son cosas que la empresa no posee. Los conectores de Revolut con los sistemas de pago son los contenedores cuyos fallos no puede eliminar con ingeniería, y el diagrama es lo que lo hace visible.

Las decisiones están junto a las cajas. Cada ejemplo tiene tres ADR, y cada ADR explica una caja que a un recién llegado le resultaría sorprendente: por qué Netflix tiene Open Connect donde otros servicios de streaming usan una CDN comercial, por qué Revolut no tiene Kafka, por qué Stripe construyó sobre MongoDB en lugar de migrar fuera de él. Si quieres el método para escribirlos, la guía completa de architecture decision records lo cubre.

Cada caja tiene un responsable. Cada artículo cierra su modelo con un mapa de propiedad: qué equipo es dueño de qué sistema o contenedor. Es el paso que convierte un diagrama en algo que alguien tiene la responsabilidad de mantener fiel.

Modela tu propio sistema

No necesitas el volumen de Stripe ni el número de servicios de Uber para que todo esto se aplique. Los mismos pasos funcionan para un sistema de diez servicios:

1. Elige una acción de usuario que importe: el checkout, el registro, lo que hace sonar el busca de alguien a las 3 de la madrugada.
2. Dibuja el nivel 1 con tu sistema como una sola caja, cada tipo de usuario y cada sistema externo que toca esa acción. Apunta a menos de quince cajas.
3. Dibuja el nivel 2 para esa acción. Solo los contenedores por los que pasa, cada uno etiquetado con su tecnología y cada flecha con un verbo y un protocolo.
4. Elige un contenedor para el nivel 3, aquel con el que una persona nueva tendría problemas, y dibuja sus componentes principales.
5. Escribe tres ADR para las tres cajas sobre las que alguien preguntará «¿por qué es así?».
6. Pon un nombre de equipo en cada contenedor.

Después repite con la siguiente acción. Tras tres o cuatro acciones, los diagramas de nivel 2 empiezan a solaparse, y ese solapamiento es tu verdadero diagrama de contenedores.

Lo que los cuatro ejemplos no pueden mostrar es lo que ocurre seis meses después, cuando el código se ha movido y los diagramas no. Ese es el problema en torno al cual está construido archyl. Conecta un repositorio y el descubrimiento por IA propone sistemas, contenedores, componentes y relaciones para que los apruebes en lugar de dibujarlos desde cero, y una puntuación de deriva contrasta después el modelo con el código para que sepas cuándo ha quedado obsoleto.

FAQ

¿Cuál es un buen ejemplo de modelo C4?

Un buen ejemplo de modelo C4 sigue una acción real del usuario a través de los niveles 1 a 3 y explica sus cajas sorprendentes. Los cuatro ejemplos de esta página (Stripe, Netflix, Uber, Revolut) lo hacen, con un diagrama de nivel 1 de unos diez sistemas, un diagrama de contenedores limitado a un camino y un zoom de componentes. Para un sistema pequeño, el ejemplo de e-commerce de arriba es una plantilla razonable.

¿Dónde puedo encontrar un ejemplo de diagrama de contenedores C4?

Cada uno de los cuatro artículos completos tiene un diagrama de contenedores de nivel 2: el núcleo de pagos de Stripe, la Streaming Platform de Netflix, el camino de asignación de Uber y el camino de transferencias de Revolut. Para un ejemplo más pequeño y desarrollado, con una tabla de contenedores y relaciones, consulta la guía del diagrama de contenedores C4.

¿Son diagramas de arquitectura oficiales de Stripe, Netflix, Uber y Revolut?

No. Cada modelo se basa por completo en la comunicación pública de la empresa, y cada artículo completo indica dónde los detalles se deducen en lugar de afirmarse. Su objetivo es mostrar cómo el modelo C4 hace legible una stack compleja, no documentar cómo funcionan hoy estas empresas.

¿Los ejemplos C4 necesitan los cuatro niveles?

Rara vez. Los cuatro ejemplos de aquí dibujan los niveles 1, 2 y 3 y se detienen. Los diagramas de nivel de código cambian con cada refactorización y suele ser mejor generarlos desde el código que dibujarlos, por eso la mayoría de los modelos C4 reales terminan en los componentes.

¿Cuántos elementos debe tener un diagrama de contexto de sistema C4?

No hay un límite oficial. En estos ejemplos, el nivel 1 va de ocho a quince sistemas más sus actores externos, para empresas con cientos o miles de servicios. Si el tuyo necesita muchos más, probablemente estés dibujando contenedores en el nivel equivocado, o necesites una vista de paisaje de sistemas que abarque varios sistemas.

¿Quieres modelar tu propio sistema en C4? Prueba archyl gratis con el plan Developer, sin tarjeta de crédito. Sigue leyendo: ¿Qué es el modelo C4? Guía completa | Guía del diagrama de contexto de sistema C4 | Guía del diagrama de contenedores C4 | Guía del diagrama de componentes C4 | Guía del diagrama de código C4.