Software Architecture
Explica cómo índices, transacciones y niveles de aislamiento protegen rendimiento e invariantes, y qué anomalías aparecen bajo concurrencia real.
Los índices aceleran accesos concretos; las transacciones agrupan cambios; el aislamiento controla qué pueden observar operaciones concurrentes. Juntos determinan si una base puede responder rápido sin romper integridad.
Una base relacional no garantiza automáticamente buen rendimiento ni concurrencia correcta. El resultado depende de cómo se modelan consultas, índices, transacciones y conflictos.
Tres preguntas guían esta nota:
Sin un índice útil, el motor puede necesitar revisar muchas filas.
tabla completa
→ examinar fila por fila
→ filtrar resultadosCon un índice compatible:
condición de búsqueda
→ navegar estructura ordenada o especializada
→ localizar filas candidatasEl índice no contiene magia. Duplica parte de la información en una estructura que favorece ciertas operaciones y encarece otras.
Cada índice consume:
Agregar índices indiscriminadamente puede empeorar inserciones y actualizaciones sin mejorar consultas importantes.
Un B-tree mantiene claves ordenadas y permite buscar, recorrer rangos y ordenar.
Es apropiado para condiciones como:
WHERE tenant_id = :tenant
AND created_at >= :from
ORDER BY created_at DESCTambién puede ayudar con igualdad, rangos y prefijos, según columnas y operador.
Otros tipos —hash, inverted, spatial, BRIN, GIN, GiST u opciones propias del motor— optimizan access patterns diferentes. Debe revisarse la documentación concreta antes de asumir comportamiento.
El orden de columnas representa cómo se navega la estructura.
Supón:
CREATE INDEX idx_orders_tenant_status_created
ON orders (tenant_id, status, created_at DESC);Puede favorecer:
WHERE tenant_id = ?
WHERE tenant_id = ? AND status = ?
WHERE tenant_id = ? AND status = ? ORDER BY created_at DESCNo necesariamente favorece una búsqueda solo por created_at o solo por status. El motor no puede aprovechar todas las combinaciones con la misma eficiencia.
La heurística del prefijo izquierdo ayuda, pero no sustituye revisar planes de ejecución y comportamiento específico.
Un índice aporta más cuando reduce de forma importante las filas candidatas.
Una columna booleana con 50 % de filas en cada valor puede ser poco selectiva. Aun así, un índice parcial puede ser útil:
CREATE INDEX idx_pending_orders
ON orders (tenant_id, created_at)
WHERE status = 'pending';Este índice contiene solo pedidos pendientes y puede ser pequeño y relevante para una consulta crítica.
Un índice unique no solo mejora acceso: protege una regla.
CREATE UNIQUE INDEX uq_product_sku_per_tenant
ON products (tenant_id, sku);Esto evita duplicados incluso si dos solicitudes concurrentes pasan la validación de aplicación al mismo tiempo.
La validación previa mejora UX, pero el constraint es la última defensa frente a carreras.
Un índice puede contener columnas suficientes para responder una consulta sin visitar la tabla, según motor y visibilidad.
CREATE INDEX idx_orders_listing
ON orders (tenant_id, created_at DESC)
INCLUDE (status, total);Reduce I/O para listados, pero aumenta tamaño y costo de escritura. Debe justificarse con medición.
EXPLAIN o equivalente muestra cómo el motor planea ejecutar una consulta.
Busca:
Un índice existente no obliga al optimizador a utilizarlo. Puede decidir que leer la tabla es más barato si devuelve gran parte de las filas.
El optimizador estima cardinalidad mediante estadísticas. Si están desactualizadas o los datos están muy sesgados, puede elegir un plan deficiente.
Problemas típicos:
La solución no siempre es otro índice; puede requerir mejores estadísticas, reescritura o particionamiento.
Una transacción agrupa operaciones que deben confirmarse o abortarse como unidad lógica.
BEGIN
→ leer y validar estado
→ modificar recursos
→ registrar movimiento
→ COMMIT o ROLLBACKLa frontera debe seguir la invariante. Una transacción demasiado pequeña permite estados inválidos; una demasiado grande mantiene locks, consume conexiones y aumenta conflicto.
Los cambios de la transacción se confirman juntos o se deshacen. No significa que los efectos externos —correo, API de pago— puedan revertirse automáticamente.
La base pasa entre estados que respetan constraints y reglas ejecutadas. ACID no conoce todas las reglas del negocio si no están expresadas o protegidas por la aplicación.
Controla cómo interfieren transacciones concurrentes. No equivale siempre a ejecución completamente serial.
Después del commit, los cambios sobreviven según configuración y garantías del motor. Replicación asíncrona, buffers o hardware pueden modificar el riesgo real.
Multi-Version Concurrency Control conserva versiones para que lecturas y escrituras interfieran menos.
Modelo mental:
fila lógica
├── versión visible para transacción A
└── versión nueva creada por transacción BCada transacción observa versiones válidas para su snapshot o statement, según aislamiento.
MVCC mejora concurrencia, pero genera versiones antiguas que deben limpiarse. Transacciones abiertas durante mucho tiempo pueden impedir cleanup y causar bloat.
Los locks coordinan acceso incompatible.
Pueden existir sobre:
Un lock pesimista puede ser correcto cuando el conflicto es probable y el recurso debe reservarse antes de actuar.
SELECT *
FROM inventory
WHERE tenant_id = :tenant
AND product_id = :product
FOR UPDATE;Después la transacción valida y modifica. Sin embargo, mantener el lock mientras se llama una API externa sería peligroso: aumenta espera y riesgo de deadlock.
Una transacción observa cambios no confirmados. Muchos motores y niveles comunes la evitan.
La misma fila produce valores distintos dentro de una transacción porque otra confirmó un cambio.
Una consulta por condición devuelve un conjunto diferente al repetirse debido a nuevas filas o eliminaciones.
Dos operaciones leen el mismo valor y una sobrescribe el cambio de la otra.
A lee stock 10
B lee stock 10
A guarda 9
B guarda 9
resultado incorrecto: se perdieron dos ventas como si fuera unaDos transacciones leen un estado conjunto válido y actualizan filas distintas, dejando una invariante global rota.
Ejemplo: dos médicos ven que el otro está de guardia y ambos se retiran, dejando cero médicos.
Los nombres pueden variar en garantía según motor. No memorices una tabla universal.
Cada statement ve datos confirmados al comenzar. Una segunda lectura puede observar cambios nuevos.
Es común y suficiente para muchas operaciones si las escrituras usan condiciones atómicas o locks adecuados.
Conserva una vista más estable durante la transacción. El comportamiento de phantoms y write skew depende del motor.
Busca que el resultado sea equivalente a alguna ejecución serial.
Puede implementar locks o detección de dependencias y abortar una transacción. La aplicación debe poder reintentar de forma segura.
Serializable no significa que las transacciones se ejecuten una por una; significa que el resultado respeta una historia serial válida.
Asume que conflictos son poco frecuentes. Se ejecuta trabajo y se verifica una versión antes de guardar.
UPDATE products
SET price = :new_price,
version = version + 1
WHERE id = :id
AND version = :expected_version;Si afecta cero filas, otro proceso modificó el registro. La aplicación puede recargar, rechazar o combinar.
Funciona bien para ediciones humanas o recursos con bajo conflicto. Bajo alta contención puede causar muchos reintentos.
Bloquea el recurso antes de modificar.
Es útil cuando:
Puede reducir carreras, pero introduce espera, deadlocks y menor throughput bajo saturación.
La reserva puede expresarse como una única modificación condicional:
UPDATE inventory
SET available = available - :qty,
reserved = reserved + :qty
WHERE tenant_id = :tenant
AND product_id = :product
AND available >= :qty;Flujo:
INSERT INTO inventory_movements (...)
VALUES (...);Si el insert falla, se revierte la actualización. Esta estrategia evita el patrón vulnerable leer–calcular–guardar.
No mantengas una transacción abierta mientras esperas:
La llamada puede tardar o completar de forma incierta. Usa estados, outbox, sagas o reservas según el flujo.
transacción local corta
→ persistir intención y outbox
→ commit
→ publicar o ejecutar efecto externo
→ reconciliar resultadoUn deadlock ocurre cuando transacciones esperan recursos retenidos entre sí.
A bloquea producto 1
B bloquea producto 2
A espera producto 2
B espera producto 1El motor aborta una víctima.
Mitigaciones:
Una transacción puede esperar locks sin estar muerta. Define límites:
Un timeout no demuestra que la operación no ocurrió. La capa superior debe conocer si puede reintentar.
Utiliza:
NOT NULL.CHECK.UNIQUE.No todas las reglas pueden expresarse fácilmente, pero las invariantes estructurales importantes no deberían depender solo de validaciones de UI.
Ambos pasan una consulta previa. El unique constraint permite uno y rechaza el otro. Traduce la violación a un error de dominio.
La transacción abortada debe ejecutar de nuevo todas las lecturas y cálculos. No reutilices resultados externos ni dupliques efectos.
Puede deberse a distribución, volumen, caché caliente o parámetros. Usa datos representativos y EXPLAIN ANALYZE con cuidado.
Una conexión queda abierta por error. Observa duración y corta transacciones excesivas.
Aumentan I/O y latencia. Revisa tamaño, working set y necesidad real.
Incrementa escritura y espacio sin representar consultas. Diseña desde access patterns.
Tiene race condition. Usa constraint y maneja conflicto.
Incluye red y rendering, retiene recursos y aumenta conflicto. Delimita el caso de uso persistente.
Puede aumentar abortos y espera sin resolver una invariante mal modelada.
Errores de validación, constraints permanentes o efectos no idempotentes no se corrigen repitiendo.
Una actualización condicional puede no modificar nada. El resultado forma parte de la lógica.
No basta ejecutar el caso de uso cien veces de forma secuencial.
Cuando la invariante puede expresarse en una sentencia corta.
Cuando el conflicto es probable y la operación es breve.
Cuando el conflicto es infrecuente y el usuario puede resolverlo.
Cuando invariantes entre múltiples lecturas/escrituras son críticas y el motor puede detectarlas, aceptando reintentos.
(tenant_id, status, created_at) no equivale a tres índices independientes?FOR UPDATE?Replicación, particionamiento y sharding explica qué cambia cuando los datos dejan de vivir en un único nodo y aparecen lag, failover, distribución y consultas cruzadas.