System Design
Gestión de cambios
Explica cómo evaluar y controlar cambios en requisitos, datos, contratos y arquitectura mediante impacto, compatibilidad, migración, rollout y rollback.
- Última actualización
- Actualizada
- Nivel
- Profundización
System Design
Explica cómo evaluar y controlar cambios en requisitos, datos, contratos y arquitectura mediante impacto, compatibilidad, migración, rollout y rollback.
Un cambio pequeño en el texto puede ser grande en el sistema. Gestionarlo bien significa seguir sus consecuencias sobre reglas, estados, datos, contratos, operación y pruebas antes de implementarlo.
La gestión de cambios mantiene coherencia mientras el sistema evoluciona. No busca impedir modificaciones, sino hacer visibles su motivo, impacto, compatibilidad, riesgo y evidencia de cierre.
nueva necesidad
→ clarificar motivo y urgencia
→ identificar artefactos afectados
→ analizar alternativas y compatibilidad
→ decidir y planificar transición
→ implementar y migrar
→ validar
→ actualizar documentación y retirar lo obsoletoSolicitud:
“Permitir pedidos programados”Impacto posible:
El análisis evita que cada equipo descubra una parte distinta durante la implementación.
Añade capacidades sin romper consumidores existentes: nuevo campo opcional, endpoint o evento.
Cambia semántica, elimina datos, vuelve obligatorio un campo o modifica identificadores.
Afecta configuración, despliegue, capacidad, alertas o procedimiento sin cambiar necesariamente el contrato funcional.
Puede tener fecha obligatoria y prioridad superior, aunque no aporte una función visible.
El comportamiento actual contradice la regla esperada. Debe decidirse cómo tratar datos históricos y consumidores que dependían del error.
Recorre la trazabilidad en ambas direcciones:
objetivo y stakeholder
↕
requisito, regla y aceptación
↕
caso, proceso, estado y dominio
↕
datos, API, evento y componente
↕
prueba, operación, migración y documentaciónPara cada elemento pregunta:
ID y título:
Motivo y fuente:
Resultado esperado:
Urgencia y fecha límite:
Supuestos:
Artefactos afectados:
Consumidores y stakeholders:
Compatibilidad:
Datos y migración:
Seguridad y privacidad:
Operación y observabilidad:
Alternativas:
Riesgos:
Decisión y owner:
Plan de rollout:
Plan de rollback:
Criterio de cierre:La compatibilidad depende del comportamiento real de consumidores. Un enum nuevo puede romper un cliente con switch exhaustivo.
anunciar
→ ofrecer alternativa
→ instrumentar uso
→ migrar consumidores
→ bloquear nuevas adopciones
→ confirmar tráfico cero
→ retirarDocumenta fecha, owner, consumidores conocidos, soporte y criterio de eliminación. “Deprecated” sin plan crea deuda permanente.
Los eventos son contratos históricos. Considera:
Un cambio en evento debe probar consumidores y datos almacenados, no solo al productor actual.
Usa migraciones compatibles y observables.
expandir
→ añadir estructura compatible
→ desplegar código que entiende ambas versiones
→ migrar y verificar datos
→ cambiar lecturas o fuente de verdad
→ contraer estructura antiguaPara una columna obligatoria:
Modificar una transición obliga a decidir qué ocurre con entidades existentes.
Ejemplo: ahora un pedido preparing ya no puede cancelarse.
Preguntas:
Permiten separar despliegue de activación, hacer rollout gradual y rollback lógico. También introducen estados combinatorios y deuda.
Cada flag necesita:
No uses flags como sustituto de compatibilidad de datos.
Opciones:
Define señales de éxito, stop conditions y rollback antes de activar.
Rollback de código no siempre revierte datos, eventos enviados o efectos externos.
Distingue:
El plan debe reflejar qué acciones son realmente reversibles.
Un hotfix puede reducir ceremonia, pero no elimina trazabilidad. Registra al menos:
La deuda de documentación debe tener owner y fecha.
Informa según impacto:
Cambio: permitir cancelar después de aprobación de pago.
Impactos:
regla
→ autorización por estado
estado
→ confirmed → cancelling → cancelled | cancellation_failed
integración
→ reembolso asíncrono
datos
→ refund_id, reason, timestamps
API
→ resultado pendiente e idempotencia
operación
→ alertar compensaciones atascadas
pruebas
→ timeout, duplicado, rechazo y recuperaciónLa petición no es un simple botón de cancelar.
Un cambio termina cuando:
Omite datos, operación y consumidores.
Es una incompatibilidad aunque compile.
La transición se vuelve estado permanente.
No se puede retirar lo antiguo con seguridad.
Código desplegado puede no estar activado ni validado.
Documentación viva define cómo conservar esta historia y evitar que los artefactos diverjan del sistema real.