Empieza por las cualidades que importan
Traduce «rápido», «confiable» y «fácil de cambiar» a escenarios que puedas probar.
AL TERMINAR, PODRÁS
- Distinguir una funcionalidad de un requisito de calidad
- Escribir un escenario de atributo de calidad medible
- Priorizar impulsores de arquitectura que compiten entre sí
Descripción del diagrama: Fuente → Estímulo; Estímulo → Artefacto; Artefacto → Entorno; Entorno → Respuesta; Respuesta → Medida
Una funcionalidad deja preguntas importantes sin responder
«Enviar un trabajo» describe una capacidad.
No dice cuánto puede tardar el envío, qué pasa durante una caída, quién puede enviar ni con qué seguridad puede cambiar esa funcionalidad. La arquitectura conecta esas expectativas con la estructura: procesos, propiedad de los datos, interfaces y dependencias. Empieza por preguntarles a los interesados (stakeholders) por las consecuencias.
Una miniatura retrasada puede ser tolerable; una instrucción de pago perdida, no. Por eso, la misma API de cola de trabajos puede requerir diseños muy distintos. Escribe el contexto antes de elegir un patrón.
Haz observable un escenario de calidad
Dale al escenario una fuente del estímulo, un evento, una condición de operación, una parte afectada, una respuesta requerida y un resultado medible.
Para Relay: en operación normal, un cliente envía uno de 100 trabajos por segundo; la API registra de forma duradera el trabajo aceptado y devuelve un ID de trabajo en menos de 250 ms para el 95 % de las peticiones. Es un objetivo de ejemplo, no el resultado de un benchmark. Especifica el tamaño del cuerpo, la ventana de medición y el comportamiento ante fallas antes de probar.
Otro escenario podría preguntar cuánto código hay que cambiar para introducir un tipo de trabajo nuevo.
Prioriza y deja ver la tensión
Un objetivo de latencia puede favorecer avisar rápido que el trabajo se recibió (acknowledge), mientras que un requisito de durabilidad exige esperar a que el almacenamiento avise que guardó los datos.
Agregar réplicas puede mejorar la tolerancia a algunas fallas y a la vez aumentar el costo y la coordinación. Elige un conjunto pequeño de impulsores junto con las personas que cargan con esas consecuencias. Separa las restricciones duras, como una política existente de residencia de datos, de las preferencias.
Registra la incertidumbre como una pregunta con un experimento, un responsable y un momento de revisión. La arquitectura no es un puntaje que se pueda maximizar en todas las dimensiones a la vez.
ERROR FRECUENTE
Elegir microservicios, una base de datos o un proveedor de nube antes de nombrar el problema y las cualidades que el diseño debe preservar.
INTÉNTALO TÚ
Reescribe «Relay debe escalar» como dos escenarios medibles: un pico de tráfico y la recuperación después de la caída de un worker. Enuncia todas las suposiciones que necesitarías para probarlos.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Escribe tres escenarios de calidad priorizados para Relay: uno de rendimiento, uno de disponibilidad y uno de modificabilidad. Nombra un interesado para cada uno.