Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 1 de 5
Brief, NFRs y arquitectura
Convierte requisitos ambiguos en una arquitectura defendible con SLO, contratos, ownership y trazabilidad hacia dominios Professional.
- Duración
- 21 min aprox.
- Objetivo
- Convierte requisitos ambiguos en una arquitectura defendible con SLO, contratos, ownership y trazabilidad hacia dominios Professional.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Proyecto Professional y simulacro de 59 preguntas
Converge las cuatro ramas en una solución production-grade y mide la preparación final.
- Diseñar y defender una plataforma completa
- Responder a fallos, costes y cumplimiento
- Completar un simulacro Professional original
01Modelo mentalBrief, NFRs y arquitectura
Convierte requisitos ambiguos en una arquitectura defendible con SLO, contratos, ownership y trazabilidad hacia dominios Professional.
+
Brief, NFRs y arquitectura
Convierte requisitos ambiguos en una arquitectura defendible con SLO, contratos, ownership y trazabilidad hacia dominios Professional.
Mostrar prerrequisitos
- Dificultad
- Professional
- Prerrequisitos
- m17, m22, m27, m31
El proyecto final comienza con decisiones, no productos. Define volumen, latencia, freshness, calidad, retención, RPO/RTO, consumidores, clasificación, regiones y presupuesto. Después asigna cada requisito a una capacidad: Auto Loader/Lakeflow Connect para ingesta, pipelines declarativos para transformación, Jobs para orquestación, Unity Catalog para gobierno y system tables para operación.
Documenta alternativas rechazadas y condiciones de cambio. Una arquitectura Professional no es la que usa más servicios, sino la que minimiza estados y responsabilidades ambiguas. Cada tabla, checkpoint, job, policy y alerta tiene owner; cada SLO tiene una señal medible y un runbook. Mapea además evidencias a los dominios del blueprint sin convertirlo en memorización.
Modelo mental
Una arquitectura Professional es una cadena de decisiones trazables, no un collage de servicios. Cada requisito se transforma primero en una propiedad medible: frescura en SLO, exactitud en reconciliaciones, seguridad en principals y policies, recuperación en RPO y RTO, y coste en unidad de valor. Después se asignan componentes que satisfacen esas propiedades y se documentan tradeoffs y fallos. Ownership y contratos definen quién responde cuando el sistema se degrada. La certificación evalúa escoger la opción más adecuada bajo restricciones, por lo que una respuesta defendible conecta requisito, mecanismo y evidencia. Si dos soluciones funcionan, gana la que usa capacidades administradas, mínimo privilegio, idempotencia y menor carga operativa sin violar una condición explícita.
Objetivo cuantitativo de fiabilidad o rendimiento, como frescura, disponibilidad o latencia, medido durante una ventana acordada.
Convierte expectativas ambiguas en criterios que guían arquitectura, alertas, capacidad y decisiones durante incidentes.Frontera donde cambian identidad, control administrativo, residencia o nivel de confianza de datos y operaciones.
Obliga a diseñar autenticación, minimización, cifrado y auditoría exactamente donde aumenta el riesgo.Registro breve del contexto, decisión, alternativas, tradeoffs y señales que justificarán revisar una elección arquitectónica.
Hace defendible el diseño y evita perder el razonamiento cuando cambian requisitos, equipos o capacidades de plataforma.product: commerce-orders
owners:
product: commerce-analytics
platform: data-platform
slos:
freshness_minutes: 15
completeness_percent: 99.95
p95_pipeline_minutes: 12
recovery:
rpo_minutes: 15
rto_minutes: 60
governance:
classification: confidential
regions: [eu-west, us-east]
finops:
monthly_budget_eur: 18000Cada valor debe enlazar a una medición y una respuesta; un SLO sin observabilidad es sólo una aspiración.
Puntos clave
- Requisitos cuantificados preceden a la selección de servicios.
- Cada componente necesita estado, owner, SLO y estrategia de recuperación.
- Registra alternativas y triggers que obligarían a revisar la decisión.
Evita
- Elegir componentes antes de aclarar latencia, volumen y ownership.
- Confundir alta disponibilidad de la plataforma con idempotencia y recuperación de la aplicación.
Recuerdo activo