Deep Dives
Investigar una pregunta significativa
En el Atlas, un Deep Dive es una investigación de diseño enfocada en una pregunta cuya significancia arquitectónica, incertidumbre, complejidad o riesgo exige más detalle que la síntesis general del High-Level Design. El objetivo es obtener evidencia para decidir, revisar una propuesta o delimitar qué falta saber.
Deep Dive no se presenta aquí como un método formal universal ni una denominación histórica única. Knowledge Map utiliza el término y el Atlas declara este framing práctico. Puede incluir análisis, experimento y conversación técnica; no se define por una reunión, una sección larga o la descripción exhaustiva de un componente.
high-level-design conserva estructura y compromisos generales; design-process contiene tanto síntesis como investigación. Un Deep Dive puede entrar en detailed design si la pregunta lo exige. Detallar endpoints, clases o configuración sin explicar qué decisión arquitectónica está en juego no cumple ese propósito por sí solo.
Elegir dónde hace falta profundidad
architectural-significance y architectural-drivers permiten priorizar consecuencias, impacto entre fronteras y riesgo de comprometer opciones costosas. Una decisión pequeña puede requerir análisis si cambia autoridad o contratos; un subsistema grande y conocido puede no necesitar otra investigación en este momento.
George Fairbanks propone ajustar técnicas y esfuerzo de arquitectura a riesgos: identificarlos y priorizarlos, elegir técnicas y evaluar reducción de riesgo. Just Enough Software Architecture, presentación del autor. Ese fundamento respalda atención proporcional, sin convertir Risk-Driven Model en sinónimo de Deep Dive ni afirmar que Fairbanks formalizó esta práctica con ese nombre.
Preguntar qué calidad importa, qué costaría fallar, qué evidencia es débil y cuánto costaría revertir. No se necesita una puntuación universal ni investigar cada componente por simetría. Curiosidad técnica puede ser valiosa, pero la prioridad de diseño requiere una preocupación relevante del alcance actual.
design-exercises permite practicar tanto elegir la pregunta como investigarla. common-pitfalls muestra cómo profundizar por simetría, validar solo el caso cómodo o presentar un prototipo como prueba global puede consumir esfuerzo sin resolver la incertidumbre decisiva.
Formular una pregunta que pueda cambiar una decisión
«Deep Dive: Database» deja el propósito abierto. «¿Puede Inventory impedir reservas incompatibles bajo la concurrencia exigida y recuperarse de un resultado incierto?» identifica una obligación. requirements-to-architecture ayuda a comprobar si esa exigencia está acordada o sigue siendo una hipótesis.
quality-attribute-scenarios concreta condiciones y respuesta esperada sin obligar a cuantificar todo con una cifra. Conviene conocer qué resultado permitiría mantener, descartar o revisar el candidato. Si cualquier resultado confirma lo ya elegido, la investigación probablemente no está discriminando alternativas.
architecture-decision-axes concentra análisis según la pregunta. Un workflow puede necesitar Coordination, Communication y Data Ownership; capacidad puede relacionar Scaling, Deployment e Isolation; almacenamiento por cliente puede requerir Tenancy, Data Ownership e Isolation. No es necesario recorrer los diez con igual detalle en cada investigación.
Secuencia, estado y fallos dentro del alcance
Un flujo merece examinar participantes, estados, autoridad y puntos donde se confirma un compromiso. Seleccionar caminos de fallo significativos además del caso feliz: respuesta perdida, reinicio, operación repetida, trabajo parcial o resultado tardío. El objetivo no es enumerar todo edge case imaginable.
coordination permite discutir resultado conjunto; saga-pattern conserva el mecanismo y sus límites cuando corresponde. timeout, retry e idempotency ayudan a interpretar una operación que podría repetirse. Estos enlaces no convierten el Deep Dive en otra definición de resiliencia ni prescriben una saga para cada colaboración.
Una investigación de datos puede precisar autoridad, modelo, concurrencia, consistencia, lifecycle y access patterns mediante data-ownership. Si existe transferencia de estado, data-migration añade preguntas de reconciliación y corte. No hace falta convertir el documento en un capítulo completo de diseño de bases.
Commerce: Inventory y reservas concurrentes
Este ejemplo propio pregunta cómo evitar overselling bajo las condiciones acordadas. Primero declarar qué significa stock disponible, quién lo modifica, cuándo una reserva se confirma o expira y qué ocurre con cancelaciones y respuestas tardías. La invariancia comercial necesita precisión antes del mecanismo.
Comparar candidatos viables dentro de esa autoridad: una operación condicional en el store existente, serialización del trabajo pertinente u otra coordinación admitida por el entorno. No afirmar cuál gana sin conocer contención, garantías, fallos y costo. isolation ayuda a separar contención de efectos de protección de un invariante; procesos distintos no resuelven automáticamente competencia sobre stock.
La evidencia puede ejercitar reservas concurrentes sobre una población representativa, fallos antes y después de confirmar y carreras entre expiración y pago. Importa saber si se perdió una respuesta o si nunca se registró la reserva. El resultado puede exigir precisar un estado o contrato en HLD, no extraer otro servicio.
Commerce: autorización con resultado desconocido
La pregunta es qué hacer si el proveedor procesó una autorización o cargo y la respuesta no llegó. El escenario necesita distinguir qué operación realiza realmente el contrato: autorizar no siempre equivale a capturar dinero. Un timeout local no demuestra fracaso remoto ni cancela por sí solo el efecto.
Investigar identificadores de operación, alcance real de idempotencia, posibilidad de consulta y evidencia auditable. No asumir que enviar la misma clave deduplica entre proveedores o después de cualquier ventana. Los contratos del SOAP existente pueden limitar las alternativas y requieren comprobación directa.
La investigación compara cómo conocer el resultado, cuándo repetir con seguridad y cómo reconciliar lo pendiente. Si faltan garantías, puede necesitarse mantener un estado incierto y una intervención posterior en lugar de prometer confirmación inmediata. Esta es una estructura de investigación del Atlas, no una implementación prescrita de pagos.
El feedback puede alterar lo que Orders entiende por aceptación y lo que Shipping espera antes de avanzar. Separar Payments podría contener ciertos efectos o añadir incertidumbre de red sin aportar beneficio suficiente. Ambos resultados son admisibles; Microservices no es una conclusión predeterminada.
Performance y capacidad con supuestos visibles
Una investigación de scaling necesita workload, tasa de llegada, mezcla, tiempos, estado y límites relevantes. CPU del frontend, conexiones a la base y cuota del proveedor responden a cargas distintas. Agregar réplicas puede ampliar una parte y dejar intacto el límite de extremo a extremo.
Como cálculo hipotético, 200 autorizaciones por segundo que ocupan en promedio medio segundo una conexión sugieren unas 100 conexiones activas en un régimen estable bajo esas condiciones. Es una aproximación de concurrencia media, no un tamaño de pool recomendado: no cubre percentiles, bursts, colas, bloqueos, fallos ni cuotas externas.
En Commerce habría que contrastar llegadas, tiempo de servicio y límite del proveedor, y observar presión sobre storage y downstream. La demanda de browsing no se convierte automáticamente en demanda de autorizaciones. Si el proveedor admite menos trabajo que el requerido, ampliar procesos propios no demuestra que el checkout pueda cumplir.
estimation desarrolla ese razonamiento y las condiciones de Little’s Law. Aquí el cálculo solo revela una hipótesis que necesita evidencia. Unidades, población y frontera deben coincidir antes de combinar medidas: requests de frontend y conexiones ocupadas por autorizaciones no describen necesariamente el mismo trabajo.
Evidencia ajustada a la pregunta
Un prototipo puede contrastar viabilidad técnica; un query plan, comportamiento del acceso; una simulación, hipótesis de coordinación; una prueba de fallos, una recuperación delimitada. La producción puede revelar distribución de latencia, uso real y puntos calientes que el modelo omitió. Ninguna evidencia cubre por sí sola todas las obligaciones.
Un benchmark necesita workload, datos, entorno, condiciones y medidas interpretables. Un test cómodo con caché caliente o dependencia simulada puede no representar el escenario. Comparar latencia sin errores, throughput útil y carga ofrecida puede premiar rechazo rápido. Registrar lo observado y lo que no se probó conserva límites de la conclusión.
El prototipo tampoco demuestra soporte, seguridad, escala y operación sostenida. La respuesta útil puede ser «esta opción parece viable bajo estos supuestos; falta comprobar tal recuperación». Una medición reproducible permite discutir la hipótesis; una demo exitosa aislada puede limitarse a mostrar que el caso seleccionado funciona.
Interfaces, entrega y transición
interfaces permite profundizar en semántica, compatibilidad, propiedad y efecto sobre consumidores, sin producir un catálogo completo de endpoints. Un contrato puede ser sintácticamente compatible y modificar significado; la investigación necesita casos que distingan ambos efectos.
deployment y deployability separan artefacto instalable de resultado de entrega segura. Investigar combinaciones de versiones, dependencia de schemas, rollback y momento de las escrituras. Cambiar tráfico o executable no restaura automáticamente información anterior.
migration-strategy aporta estados, autoridad y criterios de salida para una transición. Puede ser decisivo determinar cuándo el nuevo camino adquiere autoridad o qué historia sigue necesitando el anterior. Ese Deep Dive no reproduce toda la estrategia: resuelve la pregunta que amenaza su viabilidad.
Comparar sin fingir certeza
quality-attribute-trade-offs ayuda a exponer interacciones entre qualities. Un mecanismo puede preservar un invariante con más contención o proteger una población con capacidad ociosa. trade-off-analysis desarrolla la comparación de alternativas, costos y riesgos bajo las condiciones que hacen relevante ese compromiso; el Deep Dive investiga la incertidumbre enfocada que puede modificarla.
ADD ofrece un ejemplo de diseño y refinamiento recursivo guiado por requisitos; ATAM es un método de evaluación arquitectónica. Ninguno define todo Deep Dive ni convierte cada investigación en una iteración formal o evaluación completa.
Una revisión puede descubrir que una supuesta constraint era una preferencia, o que existe un límite nuevo. Reversibilidad y evolutionary-architecture ayudan a ajustar cuánto investigar antes de comprometerse. No hace falta certeza total, pero tampoco declarar resuelta una obligación crítica porque terminó el tiempo disponible.
Cierre y retorno a la síntesis
El resultado puede ser una decisión, candidatos descartados, alternativas acotadas, evidencia, riesgo pendiente o el siguiente experimento. No todo Deep Dive produce una respuesta final inmediata. Debe permitir entender qué cambió respecto de la pregunta original y cómo afecta al siguiente compromiso.
Conservar la pregunta, condiciones, alternativas y límites hace que otra persona pueda revisar el razonamiento. Descartar un candidato por una prueba no demuestra que todos los restantes sean adecuados. Si falta evidencia para elegir, declarar la incertidumbre y su efecto permite acordar quién la acepta o qué investigación sigue, en vez de publicar una conclusión definitiva que el análisis no sostiene.
Terminar cuando existe evidencia suficiente para decidir o revisar el alcance actual, con incertidumbre residual aceptada. Un timebox puede limitar costo, pero no prueba profundidad suficiente. Si se agota sin resolver un riesgo indispensable, corresponde cambiar el plan o aplazar ese compromiso, no inventar confianza.
fitness-functions puede sostener después una expectativa identificada, como compatibilidad entre versiones o ausencia de una dependencia. No toda evidencia debe automatizarse ni una comprobación verde decide sola. El hallazgo vuelve al high-level-design para corregir elementos, relaciones, supuestos o riesgos.
La relación HLD → pregunta significativa → investigación → evidencia y decisión → HLD revisado es una síntesis del Atlas dentro de Design Process. system-design-practice organiza ese ida y vuelta: profundidad es razonamiento suficiente para una cuestión importante, no más páginas, detalle universal ni una fase obligatoria después de aprobar un dibujo.