Design Exercises

Practicar decisiones, no memorizar diagramas

Design Exercises son, en el Atlas, problemas estructurados de práctica que requieren sintetizar requisitos, drivers, constraints, decisiones arquitectónicas, evidencia y trade-offs dentro de un alcance explícito. Entrenan razonamiento y comunicación: preguntar, proponer, contrastar y revisar. La expresión es amplia; aquí no designa un método industrial estandarizado ni una taxonomía universal de aprendizaje.

Las entrevistas pueden usar preguntas parecidas, pero el propósito es aprendizaje de ingeniería. Una fórmula para resolver «Design YouTube» en cuarenta y cinco minutos no define esta práctica. Tampoco se trata de acertar un producto, repetir una arquitectura de referencia o contestar trivia. Un coding kata suele concentrarse en implementación o diseño más localizado; puede complementar el ejercicio sin sustituir la síntesis arquitectónica.

Un case study describe y analiza un sistema real o representativo; un ejercicio pide a quien participa tomar decisiones. Los ejemplos siguientes son sintéticos y no tienen solución oficial. Diseños distintos pueden ser defendibles bajo supuestos diferentes; deben explicar esos supuestos y demostrar que no contradicen obligaciones conocidas.

Construir un problema con ambigüedad acotada

Una consigna completamente resuelta practica reproducción. Una consigna sin hechos permite inventar cualquier arquitectura. Acordar qué información existe, qué debe preguntarse y qué puede suponerse permite entrenar incertidumbre sin arbitrariedad. Un facilitador puede responder preguntas; trabajando individualmente, registrar una hipótesis y conservar otra interpretación como variante.

Una anatomía posible, síntesis editorial del Atlas, es:

Elemento	Qué permite practicar
Problema, actores y alcance	Delimitar sistema, capacidad, integración o migración observada.
Hechos y necesidades iniciales	Separar lo conocido de respuestas técnicas sugeridas.
Constraints e incógnitas	Identificar autoridad, preguntas y supuestos revisables.
Tarea de diseño	Producir decisiones y representación suficientes para el alcance.
Información posterior	Revisar ante un fallo, cambio comercial o límite descubierto.
Conversación de revisión	Examinar razones, evidencia, consecuencias y siguiente aprendizaje.

No es una plantilla obligatoria. Proporcionar solo lo que permite contrastar el objetivo elegido. Puede practicarse una frontera de Payments sin diseñar búsqueda, catálogo y analítica; una migración necesita estado actual, no solo una descripción del producto deseado. Declarar lo excluido evita confundir profundidad con diseñar todo.

Usar las prácticas sin convertirlas en fases

Comenzar por preguntas de requirements-to-architecture: resultado requerido, stakeholders, obligaciones, prioridades e incógnitas. Distinguir un requisito de un supuesto y una preferencia de una constraint. design-process integra exploración y feedback; no exige completar definitivamente la entrada antes de pensar candidatos.

high-level-design permite comunicar responsabilidades, fronteras, interacción, autoridad e implicaciones de runtime y deployment. La notación es opcional; importa qué significa cada elemento. architecture-decision-axes sirve como conjunto de preguntas según la preocupación. No es necesario responder los diez ejes con la misma profundidad ni dibujar una vista por eje.

Elegir un Deep Dive también es parte del ejercicio. Explicar qué incertidumbre podría invalidar la propuesta y por qué merece atención antes que otra. Describir muchas tablas de una base conocida mientras queda incierta la cuota del proveedor revela una prioridad discutible, aunque el detalle sea técnicamente correcto.

trade-off-analysis pide candidatos creíbles para una decisión significativa; no comparar cada elección trivial. estimation aporta cantidades solo cuando discriminan viabilidad o consecuencias. Una cuenta necesita unidades y supuestos; una afirmación cualitativa necesita razones. Documentación, investigación de fuentes, mediciones suministradas o experimentos acotados pueden fortalecer la evidencia en iteraciones posteriores.

ADD aporta un ejemplo de diseño recursivo guiado por requisitos de calidad, SEI, ADD 2.0. ATAM utiliza escenarios de uso y cambio para investigar decisiones y límites, SEI, secciones 8.7–8.8. Estos fundamentos apoyan razonamiento dirigido y revisión; no convierten los ejercicios del Atlas en ejecuciones completas de esos métodos.

Introducir cambios y conservar el razonamiento

Revelar información progresivamente permite observar si la propuesta aprende o solo defiende la primera elección. Un dato nuevo puede ser quota, residencia regional, consumidor oculto o contrato que vence. Identificar si cambia una necesidad, una restricción o la evidencia de un supuesto antes de modificar cajas.

La inyección de fallos puede plantear timeout, repetición, pérdida de un nodo o una dependencia lenta cuando sean pertinentes. No todo ejercicio necesita distribución ni caída de región. Pedir qué estado queda autoritativo, qué conoce cada participante y qué promesa continúa siendo válida; no premiar nombrar un patrón sin explicar el resultado.

Cambiar un requisito —por ejemplo, releases independientes— no demuestra que el diseño inicial fuera incorrecto bajo el contexto anterior. Una constraint nueva puede eliminar opciones antes válidas. evolutionary-architecture permite conectar revisión con intención; migration-strategy incorpora el trayecto cuando el cambio debe realizarse sobre un sistema existente.

Una progresión posible del Atlas conecta encuadre, HLD, investigación seleccionada, comparación, estimación dirigida, perturbación y revisión. Se puede volver sobre cualquier paso. No constituye un lifecycle formal, y su uso no prueba que se haya aprendido por completar documentos.

Commerce: checkout y frontera de Payments

Situación inicial. Commerce acepta órdenes, autoriza pagos, reserva inventario y organiza envíos. Negocio pide checkout con latencia aceptable, pagos auditables, inventario correcto e integración con un proveedor SOAP. Shipping puede completar trabajo después del checkout; todavía hay que aclarar qué resultado inmediato se promete.

Trabajo. Formular drivers y desconocidos; delimitar el checkout; representar responsabilidades y autoridad. ¿Qué confirma Payments? ¿Cuándo Inventory considera válida una reserva? ¿Qué puede continuar después? Elegir un fallo significativo para investigar y una decisión con alternativas: por ejemplo, frontera de entrega común o separada. No suponer cuatro servicios ni una base por responsabilidad.

Perturbaciones. El facilitador revela una quota hipotética de 250 intentos/s y latencia variable. Se espera un pico hipotético de 200 intentos/s antes de retries: preguntar ventana de cuota, otras operaciones, margen y distribución antes de considerar réplicas. Después, una respuesta puede perderse aunque el proveedor haya autorizado. Investigar timeout, idempotency y recuperación sin recibir una implementación resuelta.

Finalmente, negocio exige cambiar la integración sin releasar Orders. Revisar deployment, deployability e interfaces, no extraer un servicio automáticamente. ¿Qué parte de la propuesta anterior sigue sirviendo? ¿Qué evidencia falta sobre versiones, auditoría, resultado incierto y operación? Revisar HLD y razones, explicando qué cambió por cada nueva condición.

University Enrollment: cupos y asignación

Situación inicial. Estudiantes registran preferencias de curso y comisión. Los cupos son limitados; cuando se libera uno puede asignarse a una persona elegible. Importan corrección de inscripción, prioridad, notificación y auditoría. El alcance es asignación de plazas, no toda la plataforma universitaria.

Trabajo. Preguntar qué significa elegibilidad y fairness, quién fija la prioridad y cuándo puede cambiar. ¿Se asigna inmediatamente o por ejecución programada? ¿Qué estado es autoritativo? ¿Qué pasa si dos workers observan el último cupo? Examinar data-ownership, coordination y execution-model sin suponer que hace falta procesamiento distribuido.

Seleccionar un Deep Dive sobre la obligación más incierta y contrastar alternativas compatibles con las reglas acordadas. Preguntar qué operación debe ser idempotente y si una notificación fallida revierte o no la inscripción. El participante debe aclarar esa política con el problema, sin deducirla del mecanismo de mensajería.

Perturbación. Durante apertura de inscripción, el tráfico llega a cien veces el nivel habitual: es un dato hipotético del ejercicio, no una ley de picos. Solicitar baseline y ventana; revisar admisión, capacidad y concurrencia mediante scaling y estimation. Una queue es una posibilidad que necesita evaluación, no la respuesta requerida. Revisar también qué experimenta quien espera y cómo se conserva la prioridad.

Multi-tenant SaaS: reportes con demanda desigual

Situación inicial. Un SaaS B2B genera reportes analíticos. La mayoría de tenants son pequeños; uno empresarial produce mucho más trabajo. Se busca evitar interferencia inaceptable conservando costo y operación sostenibles. No se entrega una topología inicial ni una exigencia implícita de stack por tenant.

Trabajo. Precisar volumen, duración y prioridad de reportes, fuentes de datos y respuesta esperada. ¿Se necesita scheduling? ¿Qué constituye un noisy neighbor observable? Usar tenancy, isolation, scaling y cost-efficiency para formular criterios. Distinguir separar autoridad, recursos y deployment: no son la misma decisión.

Comparar alternativas creíbles de sharing y asignación de capacidad sin puntuaciones genéricas. Elegir qué estimar: quizá concurrencia y memoria de reportes grandes cambien la viabilidad más que usuarios registrados. Indicar qué evidencia permitiría revisar la estimación y qué límite permanece compartido.

Perturbación. El tenant empresarial requiere residencia regional para sus datos. Confirmar alcance y autoridad de la obligación dentro del escenario, sin ofrecer interpretación legal general. Revisar placement, copias, acceso, deployment y costo; no concluir automáticamente aislamiento mediante una instalación completa. ¿Qué diseño deja de ser viable y cuál conserva opciones? Actualizar los supuestos afectados, la frontera del análisis y los criterios de comparación.

Legacy Modernization: reemplazar una capacidad sin perder obligaciones

Situación inicial. Un monolith conserva comportamiento comercial estable, base compartida, pocas pruebas y runtime sin soporte. La tarea es modernizar Payments manteniendo continuidad del negocio. Se sospechan consumidores BI no inventariados. El objetivo no autoriza a eliminar contratos o historia por el solo hecho de escribir código nuevo.

Trabajo. Usar legacy-systems y refactor-vs-rewrite para aclarar necesidad y alternativas. Proponer una migration-strategy con estado actual, objetivo revisable, estados de transición, autoridad, compatibilidad y evidencia para avanzar o detenerse. strangler-fig, parallel-change y branch-by-abstraction son posibilidades para examinar según alcance, sin obligación de acumularlas.

Seleccionar una incertidumbre sobre comportamiento, escritores o datos y explicar cómo investigarla. data-migration mantiene explícita continuidad del estado. Comparar riesgo de transición, costo de coexistencia y beneficio esperado, incluyendo responsabilidades operacionales mientras ambos caminos existan.

Perturbación. Se confirma que BI lee directamente una tabla legacy en su proceso mensual. Revisar consumidores, autoridad y condición de salida: una semana sin accesos no cubre ese ciclo. ¿Cómo se conservará o reemplazará el contrato? ¿Qué evidencia necesita sunsetting y quién sostiene soporte después de deprecation? No basta mostrar el nuevo deployment funcionando.

Revisar sin una arquitectura oficial

La revisión pregunta si el diseño es coherente con hechos, supuestos y obligaciones. Dimensiones cualitativas útiles son encuadre, drivers, scope, constraints, fronteras, autoridad, interacción, fallos, razonamiento cuantitativo, trade-offs, incertidumbre, evolución y comunicación. Seleccionarlas según el ejercicio, sin pesos ni System Design Score /100.

Dar feedback concreto: pregunta omitida, supuesto no respaldado, consecuencia escondida, ownership ambiguo o alternativa más fuerte. «Arquitectura equivocada» informa poco. Pedir trazabilidad de una decisión significativa y una observación que pudiera refutarla; no premiar cantidad de tecnologías o similitud con el stack del revisor.

Self-review y peer review son opciones. Preguntar qué supuesto invalida más fácilmente la propuesta, qué cuesta revertir y dónde falta evidencia. Otra persona puede cuestionar razones sin imponer preferencias. common-pitfalls ofrece lentes para detectar solución prematura, fronteras confundidas o estimación ritual, sin convertirse en una lista mecánica obligatoria.

Repetir, variar y cerrar

Timeboxing permite practicar prioridades; trabajo sin límite corto permite mayor profundidad. Vencer el tiempo no demuestra suficiencia del diseño. Dejar explícitos decisión provisional, riesgo pendiente y siguiente investigación. Ajustar esfuerzo a las preguntas importantes es coherente con el enfoque de Fairbanks centrado en riesgos, sin atribuirle esta organización de ejercicios.

Repetir el mismo problema cambiando carga, región, lifecycle independiente o consumidores evita memorizar la primera respuesta. El contrafactual «¿qué condición haría preferible otra alternativa?» conecta práctica y Trade-off Analysis. Comparar revisiones muestra qué se sostuvo, qué se abandonó y por qué, sin asumir que mayor escala siempre exige distribución.

system-design-practice reúne las ocho prácticas y conceptos del cluster. Los ejercicios los integran, mientras cada canonical conserva su responsabilidad. El cierre útil es una propuesta explicable y un aprendizaje revisable; cuatro problemas sustanciales alcanzan aquí sin convertirse en catálogo de entrevistas, answer keys o plataforma de evaluación.