System Design
Diferencia restricciones, supuestos y dependencias para hacer visibles límites, evidencia, ownership, fallos externos y condiciones que afectan el diseño.
Las restricciones, los supuestos y las dependencias parecen información secundaria hasta que una de ellas resulta falsa. Hacerlas visibles permite diseñar con límites reales y convertir incertidumbre en trabajo verificable.
Estos tres conceptos condicionan el diseño, pero no significan lo mismo:
restricción
→ límite obligatorio que reduce alternativas
supuesto
→ afirmación temporal aceptada como verdadera
dependencia
→ capacidad o decisión controlada fuera del equipo o sistemaEjemplo:
Requisito: consultar inventario desde dispositivos de tienda.
Restricción: debe operar en los Android corporativos existentes.
Supuesto: todas las sucursales tienen conexión estable.
Dependencia: autenticación provista por identidad corporativa.Cuando estos elementos quedan implícitos, el diseño parece correcto solo dentro de un mundo ideal. El equipo puede descubrir tarde que:
El objetivo no es eliminar incertidumbre, sino identificarla, asignar responsabilidad y definir qué ocurre si cambia.
Una restricción limita las soluciones aceptables. Puede ser externa o autoimpuesta.
Una tecnología solo es restricción cuando existe una causa real. “Usaremos microservicios porque es estándar” es una preferencia o decisión, no una obligación.
Registra:
Enunciado:
Origen:
Motivación:
Vigencia:
Impacto sobre alternativas:
Excepciones posibles:
Owner:
Evidencia:Pregunta si todavía existe. Las restricciones heredadas suelen sobrevivir a la razón que las creó.
Un supuesto permite avanzar sin tener toda la información, pero debe tratarse como riesgo verificable.
Supuesto: cada sucursal procesa menos de 500 pedidos por día.
Evidencia actual: muestra de tres tiendas.
Impacto si es falso: capacidad, paginación y operación insuficientes.
Owner: producto + operaciones.
Fecha límite de validación: antes de elegir infraestructura.“Los usuarios tienen internet” es supuesto.
“El sistema tendrá modo offline” es decisión o requisito derivado.
Si el supuesto cambia, la decisión debe revisarse.
Los supuestos con alto impacto y baja evidencia deben priorizarse antes de implementar componentes costosos.
Una dependencia existe cuando el resultado necesita algo fuera del control directo.
Ejemplos:
Toda dependencia necesita contrato técnico y operativo, no solo nombre.
Dependencia:
Propósito:
Owner interno y externo:
Contrato esperado:
Fecha o disponibilidad:
SLO conocido:
Límites y cuotas:
Impacto si falla o se retrasa:
Mitigación:
Modo degradado:
Plan de escalamiento:objetivo
→ requisitos
→ sujetos a restricciones
→ apoyados en supuestos
→ ejecutados con dependenciasUna arquitectura no puede prometer más que el contexto completo. Si una dependencia crítica ofrece 99.5 % y no existe alternativa, el flujo no alcanzará 99.99 % por sí solo.
Los repartidores usan teléfonos Android de gama baja ya entregados por la empresa.
Consecuencias:
La cobertura móvil es suficiente para actualizar estados en tiempo real.
Riesgo: zonas sin señal dejan pedidos estancados.
Validación: medir rutas reales y porcentaje offline.
Posible respuesta: cola local y sincronización idempotente.
Proveedor de mapas para geocodificación.
Riesgos:
Mitigaciones: caché, segundo proveedor, entrada manual o aceptación pendiente.
Un supuesto confirmado puede convertirse en requisito o dejar de ser riesgo. Una dependencia puede imponer restricciones. Una restricción puede invalidar un supuesto.
Ejemplo:
Dependencia: proveedor solo opera en una región.
→ restricción: datos y tráfico deben salir de esa región.
→ contradicción: regulación exige residencia local.Este conflicto debe detectarse antes de diseñar integración profunda.
Escala a los owners; no existe diseño que satisfaga simultáneamente condiciones contradictorias sin renegociación.
El riesgo queda huérfano. Asigna responsable interno aunque el proveedor sea externo.
Se convierte en deuda invisible. Añade fecha y criterio de cierre.
No solo “está arriba o abajo”. Diseña timeout, bulkhead, cola o degradación.
Evita acoplar todo el dominio al contrato externo; define traducción y estrategia de migración.
Registra fecha de revisión para no convertirla en diseño permanente.
Reduce alternativas sin justificación. Pide origen y coste de cambiarla.
Una línea síncrona puede asumir disponibilidad, latencia y orden. Escríbelos.
También afectan runtime, seguridad, datos y recuperación.
Una dependencia menor puede derribar todo el flujo.
Necesitas contrato, versión, límites y responsables.
El contexto cambia, pero la documentación sigue condicionando decisiones.
Usa una matriz simple:
impacto alto + evidencia baja
→ validar primero
impacto bajo + evidencia baja
→ aceptar temporalmente y monitorear
impacto alto + evidencia alta
→ diseñar mitigaciónNo todas las preguntas abiertas merecen un spike. Prioriza por coste de equivocarse.
Reglas de negocio define las políticas y condiciones que determinan qué operaciones son válidas dentro de esos límites.