System Design
Riesgos de diseño
Explica cómo identificar, evaluar, priorizar y tratar riesgos técnicos, operativos, de datos, seguridad, dependencia y entrega durante el diseño.
- Última actualización
- Actualizada
- Nivel
- Profundización
System Design
Explica cómo identificar, evaluar, priorizar y tratar riesgos técnicos, operativos, de datos, seguridad, dependencia y entrega durante el diseño.
Un riesgo no es una preocupación vaga. Es un evento incierto que puede afectar un objetivo, con causa, consecuencia, probabilidad, impacto, owner y respuesta explícita.
La gestión de riesgos permite dedicar evidencia y controles a lo que más puede cambiar el resultado del diseño. No busca predecir todo, sino hacer visibles incertidumbres y preparar respuestas proporcionales.
Supuesto: la sucursal tiene conexión estable.
Riesgo: si la conexión es inestable, los pedidos pueden quedar sin sincronizar.
Issue: tres sucursales ya pierden conexión cada tarde.Si [causa o condición],
puede ocurrir [evento],
lo que produciría [impacto sobre un objetivo].Ejemplo:
Si el proveedor de pagos excede el timeout después de aprobar,
puede quedar un resultado desconocido,
lo que produciría cobros sin pedido confirmado o duplicados por retry.ID y título:
Categoría:
Causa:
Evento:
Consecuencia:
Probabilidad:
Impacto:
Exposición o prioridad:
Trigger:
Owner:
Mitigación preventiva:
Contingencia:
Riesgo residual:
Evidencia pendiente:
Estado y fecha de revisión:Una escala cualitativa puede bastar si tiene definiciones claras. El impacto debe considerar:
La fórmula probabilidad × impacto ayuda a ordenar, pero un riesgo raro y catastrófico puede necesitar tratamiento especial.
Cambiar el diseño para eliminar la causa. Ejemplo: no almacenar un dato sensible innecesario.
Reducir probabilidad o impacto: idempotencia, redundancia, límites o validación.
Mover parte del impacto mediante proveedor, seguro o contrato. La responsabilidad nunca desaparece por completo.
Asumir conscientemente el riesgo residual, con owner y trigger de revisión.
La mitigación actúa antes de que ocurra. La contingencia indica qué hacer después.
Mitigación: clave de idempotencia y reconciliación automática.
Contingencia: suspender retries, consultar proveedor y escalar pagos inciertos.Un riesgo necesita señales que indiquen que se está materializando:
Los triggers conectan el registro con observabilidad y decisiones.
Dos ventas concurrentes podrían comprometer el mismo stock.
Venta incumplida, ajuste manual y pérdida de confianza.
Actualización atómica, constraint y prueba concurrente.
Detectar saldo negativo, bloquear nuevas ventas, reconciliar movimientos y notificar operación.
POC con carga concurrente y métricas de conflicto.
Errores entre sistemas externos o procesos manuales todavía pueden generar diferencias.
Una sesión útil recorre:
Después asigna owners y acciones. Una lista sin seguimiento no gestiona nada.
Los controles reducen, no eliminan. Documenta qué queda y quién lo acepta. Cifrar una base reduce exposición del disco, pero no protege frente a una cuenta de aplicación comprometida con acceso legítimo.
Los riesgos cambian cuando aumenta carga, se incorpora un cliente regulado, cambia proveedor o se modifica el equipo. Revisa por evento y no solo por calendario.
Una caída regional puede afectar API, base y observabilidad simultáneamente. No los trates como eventos independientes.
Multi-región mejora recuperación, pero añade consistencia y operación.
Asignar a alguien que no puede cambiar presupuesto o proveedor no resuelve responsabilidad.
Si se acepta, debe existir justificación; si no, es deuda oculta.
Prototipos y pruebas de concepto obtiene evidencia para riesgos, supuestos y decisiones todavía inciertas.