Para preparar una presentación de arquitectura técnica, muestra tres cosas en este orden: dónde encaja el sistema, cómo lo recorre una petición importante y por qué la opción propuesta resulta preferible a las alternativas. Termina con la decisión que necesitas. Un diagrama de componentes, por sí solo, no explica el comportamiento ni las ventajas y desventajas de cada opción.
El ejemplo sigue el servicio de pedidos de una empresa minorista ficticia. Su equipo está valorando introducir una cola entre la aceptación del pedido y su preparación. La presentación debe ayudar a ingeniería y operaciones a decidir si prueban ese cambio; no constituye el diseño de un sistema real en producción.
Cuando tengas preparados los diagramas y la comparación, convierte el esquema de arquitectura en diapositivas editables con Presenti. Incluye el razonamiento técnico en el texto de entrada para que el primer borrador tenga una historia útil que organizar, en lugar de pedir a la IA que invente un sistema.
Define qué cambio debe aceptar el público
Escribe la decisión antes de crear una diapositiva: «Aprobar una prueba piloto de preparación asíncrona de los pedidos aceptados, manteniendo la autorización del pago en el flujo actual». Añade los límites: la integración con el proveedor de pagos, la sustitución de la base de datos y el rediseño completo del proceso de compra quedan fuera de esta conversación.
Esa frase determina qué detalles deben entrar en la presentación. La persona responsable de operaciones necesita saber qué ocurre cuando se retrasa una tarea de preparación. La persona responsable de ingeniería necesita entender cómo se gestionan los reintentos y los duplicados. Ninguna necesita un recorrido por todos los servicios de la empresa. Si aún no hay acuerdo sobre el comportamiento esperado del usuario, acláralo en una presentación de requisitos de producto antes de pedir que esta revisión elija una arquitectura.
Empieza por los sistemas que lo rodean
Utiliza una vista de contexto con el cliente, la aplicación de compra, el servicio de pedidos, el proveedor de pagos y el servicio de preparación de pedidos. Etiqueta las relaciones con su propósito, no solo con una flecha. «Autoriza el pago» explica más que «API». Identifica el servicio de pedidos como el elemento que se está analizando y coloca los sistemas externos fuera de ese límite.
La guía de contexto de sistemas de C4 recomienda esta vista general del sistema, sus usuarios y los sistemas conectados antes de introducir detalles de bajo nivel. No necesitas adoptar todos los diagramas de C4 para separar así las distintas vistas.
Sigue un pedido desde su aceptación hasta su preparación
Utiliza un recorrido numerado para explicar qué cambia con la cola propuesta. El siguiente flujo corresponde a la empresa ficticia del ejemplo. Los números deben coincidir con el diagrama para que quien presenta pueda señalar cada paso sin tener que buscar un recuadro.
| Paso | Interacción | Qué debe entender el público |
|---|---|---|
| 1 | La aplicación de compra envía una petición al servicio de pedidos | La petición tiene un identificador de pedido que permite seguir todo el recorrido |
| 2 | El servicio de pedidos confirma la autorización del pago | Un pago rechazado no genera una tarea de preparación |
| 3 | El servicio registra el pedido aceptado y un evento pendiente | El diseño debe contemplar un fallo entre el registro del pedido y la publicación del evento |
| 4 | Un publicador envía el evento pendiente a la cola | La publicación puede reintentarse; el evento necesita un identificador estable |
| 5 | El servicio de preparación recibe el evento y registra su estado de procesamiento | Un evento repetido no debe generar un segundo envío |
| 6 | Operaciones consulta el estado de la tarea o recibe una alerta de fallo | La cola cambia tanto la supervisión y la recuperación como el recorrido de la petición |
Un diagrama dinámico de C4 permite representar interacciones ordenadas durante la ejecución de un caso de uso. Úsalo de forma selectiva: aquí interesa el camino de los fallos y los reintentos, no cada llamada que termina correctamente.
No describas este ejemplo como un procesamiento «exactamente una vez» ni como un sistema «sin pedidos perdidos». Esas afirmaciones requieren detalles de implementación y pruebas que la presentación no aporta. Señala, en cambio, las preguntas de diseño: cómo se recuperan los eventos pendientes, cuánto tiempo se conservan las tareas fallidas y quién se encarga de volver a procesarlas.
Compara las opciones con los mismos criterios
Una diapositiva comparativa no debería colocar un párrafo de ventajas junto a otro de inconvenientes. Utiliza criterios idénticos y muestra el coste de cada opción.
| Criterio | Llamada directa al servicio de preparación | Preparación mediante cola |
|---|---|---|
| Respuesta al cliente | La aceptación depende del comportamiento de la llamada al servicio de preparación | La aceptación puede separarse del procesamiento posterior |
| Recuperación ante fallos | Los reintentos permanecen en el flujo de la llamada | Requiere estados de tarea, reprocesamiento y gestión de duplicados |
| Trabajo operativo | Hay menos elementos que gestionar en este flujo | La salud de la cola, las tareas fallidas y el retraso de procesamiento necesitan responsables |
| Migración | No introduce un nuevo recorrido de mensajes | Requiere una prueba piloto y una vía para revertir el cambio |
La tabla describe aspectos del diseño, no un rendimiento medido. Añade datos reales de latencia o errores solo si puedes indicar el entorno, el periodo, la muestra y la fuente. Sin esos datos, la recomendación honesta es una prueba piloto acotada, no una mejora que se da por demostrada.
Organiza el argumento en seis diapositivas
- Decisión y alcance: la prueba piloto propuesta y sus exclusiones.
- Contexto: el servicio de pedidos y los sistemas directamente conectados.
- Problema actual: el incidente observado, el retraso o la limitación operativa que motivó la propuesta.
- Recorrido propuesto: las seis interacciones y los puntos de fallo.
- Opciones: los mismos cuatro criterios de comparación para ambas alternativas.
- Decisión sobre el piloto: responsable, vía de reversión, pruebas y fecha para decidir si se continúa.
En este ejemplo, la última diapositiva podría pedir al equipo de plataforma que pruebe un fallo del publicador, una entrega duplicada y una caída del servicio de preparación antes de evaluar el piloto. Cada prueba necesita un resultado esperado y una persona responsable de interpretarlo. Así la reunión produce algo concreto sin fingir que la presentación resuelve por sí sola la arquitectura. Una vez completadas esas pruebas, una presentación de preparación para el lanzamiento conecta sus resultados con la versión candidata concreta, los bloqueos pendientes y la persona autorizada para decidir si se lanza o no.
Crea el borrador de seis diapositivas en Presenti con tu propio recorrido, tabla de opciones y condiciones del piloto. Guarda la configuración, los registros y los resultados completos de las pruebas en un anexo o en un documento de diseño enlazado, donde se puedan consultar sin sobrecargar el argumento principal.
