System Design
Explica cómo equilibrar normalización, duplicación, invariantes y consistencia para conservar integridad sin ignorar patrones de acceso y límites operativos.
Normalizar busca que cada hecho tenga un lugar claro. Desnormalizar busca responder una necesidad concreta duplicando información de forma controlada. Ambas decisiones deben partir de integridad, consultas y operación.
La normalización organiza datos para reducir redundancia y anomalías. La consistencia define qué relaciones y reglas deben mantenerse verdaderas, incluso ante fallos o concurrencia.
Una tabla única de ventas podría repetir nombre del cliente, dirección, producto y precio en cada fila. Cambiar un dato exigiría modificar muchas filas y podría dejar versiones contradictorias.
Las anomalías clásicas son:
un hecho
→ una fuente de verdad
→ reglas que protegen relaciones
→ copias explícitas con propósito
→ mecanismo de sincronizaciónCada fila es identificable y cada atributo contiene un valor del dominio esperado. Guardar "A1,B2,C3" en una columna impide validar relaciones y consultar con claridad.
En una tabla con clave compuesta, los atributos dependen de toda la clave. En OrderLine(orderId, lineNumber, productName), el nombre actual del producto no depende de toda la clave si representa catálogo; quizá pertenece a Product. Si representa snapshot histórico, su significado cambia y debe documentarse.
Los atributos no clave no dependen transitivamente de otros atributos no clave. Guardar branchCity junto a branchId en cada pedido duplica información si la ciudad es propiedad actual de la sucursal.
Las formas normales son herramientas de razonamiento, no una meta mecánica.
Primary keys, foreign keys, NOT NULL, UNIQUE y CHECK impiden estados inválidos básicos.
Varias modificaciones relacionadas deben confirmarse o revertirse juntas cuando la regla exige atomicidad.
Algunas reglas requieren lógica adicional: límites acumulados, solapamiento temporal o transición de estado.
Cuando existen varias fuentes, no siempre puede garantizarse atomicidad global. Se necesitan contratos, idempotencia, reconciliación y estados intermedios.
CREATE TABLE inventory_item (
branch_id uuid NOT NULL,
product_id uuid NOT NULL,
on_hand numeric(12,3) NOT NULL CHECK (on_hand >= 0),
reserved numeric(12,3) NOT NULL CHECK (reserved >= 0),
version integer NOT NULL DEFAULT 0,
PRIMARY KEY (branch_id, product_id),
CHECK (reserved <= on_hand)
);La clave impide duplicados por sucursal y producto. Los checks protegen reglas locales. Aun así, una reserva concurrente necesita una operación atómica; el esquema por sí solo no define todo el flujo.
Dos procesos leen el mismo valor y escriben resultados basados en una versión antigua.
Dos operaciones comprometen el mismo recurso.
Un mensaje antiguo sobrescribe un estado más nuevo.
Una réplica o caché devuelve información anterior.
La solución depende de la garantía requerida: locks, control optimista, restricciones, serialización, versionado, idempotencia o reconciliación.
UPDATE inventory_item
SET reserved = reserved + :quantity,
version = version + 1
WHERE branch_id = :branchId
AND product_id = :productId
AND on_hand - reserved >= :quantity;Si se actualiza cero filas, no existe capacidad suficiente o el registro cambió. La comprobación y modificación ocurren juntas, evitando una ventana entre lectura y escritura.
Una copia puede existir por:
Cada copia debe declarar:
La desnormalización debe tener una hipótesis medible y mecanismo de reparación.
Decide entre:
order_total puede almacenarse como hecho confirmado, mientras current_cart_total puede calcularse. El significado determina la decisión.
Soft delete mantiene la fila, pero afecta:
Para historial complejo puede ser mejor una tabla de versiones, eventos o periodos de vigencia en lugar de añadir deleted_at a todo.
No existe una única consistencia universal. Una operación puede requerir:
Define la garantía por flujo y dato.
Usa claves de idempotencia o constraints que representen la identidad de la operación.
Incluye versión, secuencia o regla que rechace actualizaciones antiguas.
Una nueva proyección debe poder reconstruirse sin bloquear el sistema principal.
Durante despliegues coexistirán versiones. Usa cambios expand-and-contract y contratos compatibles.
Define TTL, invalidación, tolerancia a staleness y fallback.
Cuando el problema no está medido, el volumen es bajo o el coste de sincronización supera el beneficio. Un join bien indexado suele ser más seguro que una copia manual.
Diagramas de clases separa estructura y comportamiento orientado a objetos del modelo persistente.