3.4 Arquitectura de datos y almacenamiento

Panorama y motivación

Los datos perduran mucho más que el código. Las aplicaciones se reescriben cada pocos años, pero los datos que gestionan (registros de clientes, balanzas financieras, historiales de prestaciones, expedientes de salud) siguen vivos durante décadas. En muchos casos, son el activo más valioso y, a la vez, el más regulado de toda la organización. La arquitectura de datos es la disciplina que define cómo se modela, dónde se almacena, cómo se mantiene su integridad, cómo evoluciona y cómo se sirve a la velocidad que la escala exige. En una gran organización, estas decisiones son fundamentales: la elección de motores de almacenamiento y modelos de datos condiciona lo que el negocio puede hacer, a qué ritmo puede avanzar y cuánto le cuesta, durante toda la vida útil del sistema.

El riesgo es mayor en el ámbito empresarial y gubernamental por la convergencia de escala, longevidad y regulación. El almacén de transacciones de un banco no puede perder ni duplicar un solo céntimo. Un registro público debe conservar los documentos durante los plazos legales y poder demostrar su integridad ante los auditores. Un sistema sanitario debe aplicar reglas de acceso y de residencia de datos de extrema granularidad. Y, al mismo tiempo, estas organizaciones atienden volúmenes de lectura y escritura enormes, de modo que no pueden permitirse que cada consulta impacte sobre una única base de datos relacional. La arquitectura de datos debe conciliar la corrección y la durabilidad con el rendimiento y la escala, y hacerlo mientras el esquema sigue cambiando para adaptarse a nuevos requerimientos normativos.

Este capítulo abarca los grandes paradigmas de almacenamiento y cuándo conviene cada uno, la disciplina de la persistencia políglota, el modelado de datos y el problema a menudo subestimado de la evolución del esquema y las migraciones, la caché y las CDN (redes de distribución de contenido) con su notoriamente difícil problema de la invalidación, y cómo se comportan las transacciones, los bloqueos y la concurrencia cuando se lleva el sistema a gran escala. El hilo conductor es simple: no existe una base de datos universal. Existen compensaciones, y buena arquitectura de datos significa elegirlas con plena conciencia, un caso de uso a la vez.

Principios fundamentales

Modela los datos en función de los patrones de acceso, no al revés. Diseña el almacenamiento según cómo se leerá y escribirá la información, no según un modelo abstracto de «correcto».
No hay una sola base de datos que sirva para todo. Cada caso de uso pide un motor distinto; la persistencia políglota es lo normal a gran escala.
La corrección ante todo en los sistemas de registro. En los datos de autoridad, la durabilidad y la consistencia no admiten negociación; optimiza el rendimiento en torno a ellas, no a costa de ellas.
El esquema va a cambiar: prepárate para ello. Las migraciones son una actividad de ingeniería continua y de primera clase, no un acto puntual.
Cada servicio es dueño de sus datos tras un límite de servicio. Cada contexto delimitado (un modelo de dominio autónomo con su propio perímetro explícito) es responsable de sus datos; compartir una base de datos acopla equipos y destruye la autonomía.
La caché es un problema de corrección disfrazado de ganancia de rendimiento. Toda caché introduce riesgo de obsolescencia y de invalidación; trátala con deliberación.
La desnormalización es un intercambio legítimo, no un pecado. Duplicar datos para mejorar el rendimiento de lectura es válido si se asumen las consecuencias en la consistencia.
La consistencia y la escala compiten entre sí. A mayor garantía transaccional, más difícil es distribuir; adquiere solo lo que el caso de uso exige.

Recomendaciones

Elige el paradigma de almacenamiento según el caso de uso

Ajusta cada caso de uso al modelo que le conviene. La base de datos relacional ofrece consistencia fuerte, joins y transacciones maduras; es la opción por defecto para sistemas de registro y todo lo que implique reglas de integridad complejas. Los almacenes de documentos (document-oriented) encajan con datos jerárquicos y esquemas flexibles que se leen como una unidad completa (un pedido entero, un perfil completo). Los almacenes de clave-valor (key-value) ofrecen velocidad extrema para consultas simples (sesiones, feature flags, caché). Las bases de datos gráficas (graph) brillan cuando las relaciones son la consulta en sí (redes de fraude, organigramas, derechos y prestaciones, cadenas de suministro). Los almacenes columnares (column-oriented) impulsan consultas analíticas que escanean pocas columnas sobre miles de millones de filas (data warehouses, reportes). Las bases de datos de series temporales (time series) optimizan datos con predominio de escritura por追加 y con marcas de tiempo (métricas, telemetría, sensores del Internet de las Cosas, datos de mercados). No fuerces a un solo motor a hacer todos los trabajos. Usar una base relacional como cola de mensajes, o un almacén de documentos como libro contable, es pedir problemas.

Adopta la persistencia políglota con deliberación

Los sistemas grandes emplean legítimamente varios almacenes: un sistema de registro relacional, un índice de búsqueda, una caché, un warehouse analítico y, quizás, un motor grafo o de series temporales. Esta es la persistencia políglota, y es el patrón adecuado cuando los casos de uso son genuinamente distintos. El coste es operativo, porque ahora hay más motores que ejecutar, proteger, hacer copia de seguridad y mantener con personal cualificado. Gestiona ese coste asignando cada almacén a un servicio, estandarizando las herramientas operativas y limitando el número de tecnologías a las que realmente justifican su presencia. Desconfía de quien añade un nuevo almacén por cada necesidad menor: cada uno es un compromiso operativo permanente.

Modela los datos y trata la evolución del esquema como un proceso continuo

Invierte en el modelado de datos desde el inicio en los sistemas de registro. Normaliza para proteger la integridad y desnormaliza de forma selectiva donde se demuestren cuellos de botella en lectura. Sea cual sea el modelo, el esquema evoluciona de forma permanente, así que haz que las migraciones sean seguras y rutinarias. Utiliza guiones de migración versionados, automatizados y de solo avance, bajo control de versiones y aplicados a través de la pipeline de despliegue. Para cambios sin interrupción en tablas grandes, aplica el patrón de expansión-contracción (parallel change): añadir la columna o tabla nueva, completar los datos retroactivamente, escribir en paralelo a ambos formatos, migrar a los lectores y, por último, retirar el formato antiguo. Nunca una operación de ALTER destructiva en un solo paso. Asegura que los cambios de esquema sean compatibles hacia atrás entre despliegues para que código viejo y nuevo puedan coexistir. En sistemas basados en eventos o en mensajería, versiona explícitamente los esquemas de eventos y mensajes y da soporte a la upcasting de eventos antiguos (transformándolos al esquema actual en tiempo de lectura).

Diseña la caché y la invalidación con los ojos abiertos

La caché y las CDN son las herramientas de mayor palanca en rendimiento. Una CDN sirve contenido estático y cacheable desde el borde, cerca del usuario; una caché de aplicación libera a la base de datos de lecturas repetidas. Pero la parte difícil es la invalidación: saber cuándo los datos en caché están obsoletos. Elige una estrategia para cada caso. Usa expiración temporal (TTL) cuando una ligera obsolescencia es aceptable y resulta la opción más simple. Usa invalidación explícita o escritura directa (write-through) cuando la frescura importa. Usa cache-aside cuando la propia aplicación gestiona la carga. Ajusta los TTL de forma consciente, protege contra las avalanchas de caché (muchos clientes reconstruyendo al mismo tiempo la misma entrada expirada) con bloqueos o request coalescing, y evita el efecto de enjambre en caché frías. Nunca caches datos cuya obsolescencia pueda provocar un fallo de corrección o de cumplimiento (derechos, saldos, consentimientos) sin una ruta de invalidación explícita y probada. Trata las claves de caché, los TTL y la invalidación como artefactos de diseño, no como configuración incidental.

Gestiona transacciones, bloqueos y concurrencia a escala

Comprende los niveles de aislamiento y elige el más débil que siga siendo correcto para cada transacción, porque a mayor aislamiento, mayor costo en concurrencia. Prefiere la concurrencia optimista (verificación de versión al escribir) para cargas de bajo conflicto y alta lectura, y recurre al bloqueo pesimista solo ante contención intensa y real, manteniendo los bloqueos cortos y en un orden consistente para evitar deadlocks. A medida que crece la escala, una base de datos de escritura única se convierte en el cuello de botella. Introduce réplicas de lectura para escalar las lecturas (aceptando un desfase de replicación) y fragmenta/particiona (shard/partition) por una clave que distribuya la carga de forma uniforme y mantenga juntos los datos relacionados, evitando así transacciones interfragmento. Ten presente que la fragmentación sacrifica los joins entre particiones y las transacciones ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) multi-partición, lo que a menudo explica por qué aparecen sagas y desnormalización. Aplica estas técnicas solo cuando el caso de uso lo exija. Fragmentar de más añade complejidad permanente sin beneficio.

Compensaciones: ventajas y desventajas

Tipo de almacén	Ideal para	Fortalezas	Debilidades
Relacional	Sistemas de registro, integridad compleja	ACID, joins, herramienta madura	Dificultad para escalar escrituras en horizontal
Documental	Lecturas de agregados, esquema flexible	Lectura/escritura rápida de objeto completo, flexibilidad	Joins y transacciones interdocumentos débiles
Clave-valor	Sesiones, caché, consultas simples	Velocidad y escala extremas	No permite consultas más allá de la clave
Grafo	Consultas centradas en relaciones	Recorridos rápidos y expresivos	Perfil operativo de nicho, límites de escala
Columnar	Analítica, reportes	Escaneos de agregados rápidos, alta compresión	Poca aptitud para escrituras transaccionales a nivel de fila
Series temporales	Métricas, telemetría, IoT	Escritura y consultas temporales muy eficientes	Uso de alcance acotado

La compensación dominante es la tensión entre consistencia fuerte y consultas ricas, por un lado, y escalabilidad horizontal y velocidad, por el otro. Los sistemas relacionales ofrecen las garantías más sólidas y las consultas más flexibles, pero son los más difíciles de escalar en escrituras sobre múltiples nodos. Las familias NoSQL (no relacionales) relajan joins, transacciones o esquema a cambio de escala y velocidad. La caché intercambia frescura por latencia. La fragmentación intercambia transacciones interpartición por capacidad de escritura. Ninguna opción es universalmente correcta. El arte consiste en situar cada caso de uso en el punto de la curva que su necesidad real de corrección y rendimiento exige.

Pautas para el debate con el equipo

Para cada conjunto de datos crítico, ¿puede todo el equipo nombrar un único sistema de registro, o son las cachés y las proyecciones las que en silencio pasan a tratarse como verdad? Los datos perduran más que el código, y los incidentes más graves de datos provienen de la drift: una caché, un índice de búsqueda o una proyección de lectura se toma por autoridad y diverge silenciosamente de la fuente real. En un equipo grande, esto ocurre cuando la propiedad es difusa y varios servicios escriben copias superpuestas, de modo que nadie puede decir cuál es el valor correcto durante un incidente. Trae un mapa de tus datos importantes y, para cada uno, el almacén único que es autoritativo más las copias derivadas que deben poder reconstruirse a partir de él. En finanzas y en el sector público, poder demostrar cuál es el registro legal y reconstruir todo lo demás suele ser un requisito regulatorio, no una conveniencia. Lo que no pueda reconstruirse desde el sistema de registro se convierte, quieras o no, en un sistema de registro a su vez.
¿Qué le cuesta realmente operar, proteger y respaldar cada motor de base de datos de tu infraestructura, y sigue cada uno justificando su lugar? La persistencia políglota es correcta cuando los casos de uso son genuinamente distintos, pero cada motor es un compromiso operativo permanente: parches, copias de seguridad, monitorización, revisión de seguridad y personal que lo conozca a las tres de la madrugada. Una gran organización puede derivar en un zoológico de almacenes, cada uno adoptado para una funcionalidad puntual, y el último suma coste para siempre sirviendo un caso que un almacén ya en operación podría cubrir. Enumera cada motor, el caso de uso que lo justifica y quién atiende el turno de guardia, y marca los adoptados por una necesidad que el almacén principal ya podría resolver hoy. La adopción de un nuevo almacén debe superar un umbral elevado, porque retirarlo después implica otra migración. Estandarizar las herramientas operativas en los almacenes que se conserven es la forma de contener el coste sin forzar a un solo motor a todo.
¿En qué flujos un usuario podría leer un valor obsoleto desde una réplica justo después de haber escrito, y eso rompe alguna promesa hecha al usuario? Las réplicas de lectura escalan las lecturas, pero van detrás de la primaria, así que un usuario que actualiza su perfil y recarga de inmediato puede ver el valor anterior, lo que se percibe como un fallo o, en el caso de un saldo o un consentimiento, como una incumplimiento de norma. Decide, por flujo, si la lectura propia tras escritura (read-your-writes) es imprescindible, y encausa esas lecturas a la primaria o usa un mecanismo de consistencia por sesión. Trae la lista de flujos servidos desde réplicas y marca cuáles son los que el usuario ejecuta inmediatamente después de escribir. Para saldos, derechos y consentimientos, trata las lecturas obsoletas como fallos de corrección, no como un detalle cosmético. Se trata de adquirir solo la consistencia que cada caso de uso necesita y de hacer que la obsolescencia que sí se acepta sea explícita, no accidental.
¿Puedes modificar hoy el esquema de tu tabla más grande y más transitada sin interrumpir el servicio, y quién ha ensayado de verdad los pasos de expansión-contracción? El esquema evoluciona de forma permanente, y el fallo más dañino es una modificación destructiva de una sola vez que bloquea una tabla enorme, congela el servicio y no permite un rollback limpio. En un equipo grande, el riesgo se multiplica porque varios servicios leen el mismo formato, de modo que un cambio destructivo exige que código antiguo y nuevo convivan durante un despliegue escalonado. La tensión es real: una sola sentencia de ALTER es rápida de escribir, pero el patrón de expansión-contracción (añadir el formato nuevo, completar los datos, escribir en paralelo, migrar lectores, retirar el formato antiguo) implica más pasos y más paciencia. Trae tu tabla más grande, una estimación honesta de cuánto tiempo bloquearía un ALTER ingenuo y una migración concreta que alguien haya ejecutado de principio a fin en un ensayo, no en teoría. En sistemas empresariales y gubernamentales que operan sin interrupción y que tienen objetivos de disponibilidad normativos, una parada por migración es una violación, de modo que la disciplina de expansión-contracción es el precio a pagar por tener el derecho a modificar el esquema.
¿Qué valores cacheados o replicados, si se sirven obsoletos, causarían un fallo de cumplimiento o de seguridad en lugar de un mero defecto cosmético, y cada una de esas rutas de invalidación está probada en la práctica? La caché es un problema de corrección con traje de rendimiento: el peligro no es la lentitud, sino servir un derecho, un saldo, un consentimiento o una decisión de acceso después de que ha cambiado. En una gran organización, el riesgo se difunde, porque las capas de caché y de borde se acumulan entre equipos y no hay una sola persona que pueda listar qué se cachea dónde y cuándo se limpia. La tensión es real: cachear con agresividad y TTL largos compra latencia y protege la base de datos, mientras que la frescura estricta tiene un coste en ambos frentes. Trae un inventario de datos cacheados y servidos por CDN, marcados para indicar cuáles tienen una consecuencia de cumplimiento o de seguridad, junto con la evidencia de que la ruta de invalidación de cada uno de ellos se ha ejercitado en la práctica, no solo configurado. En contextos regulados y públicos, un consentimiento o un criterio de elegibilidad obsoleto es un fallo auditable, por lo que esos elementos requieren una ruta de invalidación explícita y probada o no deben cachearse en absoluto.
¿Cuál es tu estrategia de retención, archivo y residencia de datos para cada almacén de autoridad, y puedes demostrarla a un auditor? Los datos perduran más que el código y, a menudo, más que el equipo que los creó, de modo que el crecimiento sin límites y las normas de residencia vagas se convierten en el problema que nadie asume hasta que una tabla resulta ingobernable o un registro permanece en la jurisdicción equivocada. Una gran organización abarca múltiples almacenes y regiones, y las consideraciones en tensión son coste (el almacenamiento caliente es caro, así que hay que archivar y estratificar), rendimiento (las tablas hinchadas ralentizan todo) y deber legal (plazos mínimos de retención normativa y límites de residencia que pueden entrar en conflicto). Trae, por cada conjunto de datos autoritativo, el período de retención, dónde reside físicamente, el mecanismo de archivo y eliminación, y el nombre de la persona responsable. En el sector empresarial y, sobre todo, en el público, la retención y la residencia suelen ser mandatos legales con requisitos de auditoría y soberanía, por lo que poder demostrar dónde reside cada registro, cuánto tiempo se conserva y cuándo se destruye es un requisito para operar, no una concesión.

Perspectiva por sector

Startup. Usa una sola base de datos y resiste la tentación del zoológico. Un único almacén relacional gestionado te da transacciones, una sola cosa que respaldar y un solo lugar en el que razonar sobre la consistencia, que es exactamente lo que un equipo de tres personas puede mantener en su cabeza. Añade una caché, una réplica de lectura o un índice de búsqueda solo cuando una consulta lenta y un volumen real de lecturas lo exijan, de modo que la complejidad llegue con una razón pagada, no por anticipado. Mantén las migraciones versionadas desde el primer día, porque implantar esa disciplina en un producto ya en producción es mucho más difícil que arrancar con ella.

Pequeña empresa. No tienes un especialista de bases de datos ni tiempo para operar varios motores, así que opta por un almacén gestionado y deja que tu proveedor de plataforma se encargue de respaldos, parches y replicación. Trata la elección del almacén como una decisión de compra: elige el motor aburrido, bien soportado y compatible con tus herramientas existentes, en lugar del más rápido de un benchmark. Define una política simple de retención y copia de seguridad que puedas verificar de verdad, y nunca caches nada vinculado a dinero o permisos sin una forma clara de purgarlo, porque un precio obsoleto o un derecho incorrecto te cuesta un cliente.

Empresa grande. El reto central es la persistencia políglota entre muchos equipos: un sistema de registro relacional junto con búsqueda, caché, warehouse analítico y, quizás, motores de grafo o series temporales, cada uno propiedad de un servicio, nunca compartido. Estandariza las herramientas operativas, los respaldos y la monitorización en los almacenes que se conserven, exige un umbral elevado para la adopción de nuevos motores e impone como norma la migración de expansión-contracción y la invalidación explícita de caché. Gestiona la infraestructura como un portafolio con propiedad de datos clara, de modo que ningún motor sobreviva más allá del caso que lo justificó y ningún equipo se acople a través de una base de datos compartida.

Sector público. La residencia de datos, la retención legal y la integridad demostrable condicionan cada elección. Provisiona cada almacén en regiones soberanas, configura las CDN para cachear únicamente datos no personales y conserva un historial de auditoría inmutable para los registros que deben ser reconstruibles ante los reguladores. Las migraciones impuestas por nuevas leyes deben aplicarse de forma compatible hacia atrás a través de la pipeline para que el servicio permanezca disponible durante los plazos legislativos, y el sistema de registro debe ser identificable para poder demostrar cuál es el valor legal y reconstruir de él cada copia derivada.

Ejemplos

Startup. Una startup en fase de semilla opera todo sobre una única instancia de PostgreSQL gestionada y resiste el impulso de añadir un motor de búsqueda, una caché y un warehouse analítico antes de necesitarlos. Una sola base de datos significa una sola cosa que respaldar, un solo lugar en el que razonar sobre la consistencia y transacciones que funcionan sin más, lo que importa cuando todo el equipo son tres ingenieros. Añaden una caché Redis y una réplica de lectura solo cuando una consulta concreta y lenta y un volumen real de lecturas lo justifican, de modo que la complejidad llega con una razón que la sostiene, no por anticipado.

Empresa grande. Un banco minorista mantiene su libro contable autoritativo en una base de datos relacional de consistencia fuerte: cada asiento es una transacción ACID propiamente dicha, fragmentada por rango de cuentas para escalar las escrituras. En torno a ella se despliega un ecosistema políglota: un índice de búsqueda para el localizador de clientes, una caché Redis (escritura directa, TTL corto) con los resúmenes de cuenta de la app móvil, un warehouse columnar para la reportación analítica y regulatoria, y una base de datos de grafo para la detección de fraude en redes de transacciones. Los cambios de esquema del libro contable se aplican mediante expansión-contracción con escritura en paralelo para que el sistema de 24/7 nunca sufra una interrupción por una migración.

Sector público. Un registro vehicular nacional almacena los registros autoritativos en un sistema de registro relacional con retención legal e historial de auditoría completo. Las consultas públicas de «verificar un vehículo» se sirven desde una réplica de lectura y una caché de borde con TTL corto, porque unos datos públicos ligeramente obsoletos son aceptables y el volumen de lecturas supera con creces el de escrituras. La ley de residencia de datos exige que todos los registros permanezcan dentro del territorio, así que cada almacén se provisiona en regiones soberanas y la CDN se configura para cachear únicamente datos no personales. Las migraciones para añadir campos que impone la nueva política de transporte se aplican de forma compatible hacia atrás a través de la pipeline, de modo que el servicio permanece disponible durante los plazos legislativos.

Casos de negocio: motivación, retorno y coste total

Las decisiones de arquitectura de datos tienen entre las colas de coste más largas y elevadas en el software, porque los datos y su esquema son lo más difícil de modificar una vez que los sistemas e integraciones dependen de ellos. El coste de adoptar buenas prácticas (selección deliberada del almacén, migraciones disciplinadas, caché diseñada y fragmentación adecuada) es, en su mayoría, tiempo de ingeniería senior y algo de herramienta operativa adicional. El coste de no adoptarla se manifiesta como una base de datos sobrecargada que estrangula a todo el negocio, una replataforma de emergencia cuando el almacén inadecuado se descubre demasiado tarde, interrupciones prolongadas por una migración mal ejecutada y, lo más dañino, una corrupción de datos o una violación de cumplimiento por una caché mal invalidada o una transacción perdida.

Presenta el caso ante la dirección en términos de capacidad de escala, riesgo de incidentes y exposición regulatoria. Las elecciones correctas de almacenamiento son lo que permite al negocio crecer en volumen de lecturas y escrituras sin una reescritura. Las migraciones disciplinadas son lo que permite al esquema mantenerse al día con los nuevos requerimientos sin interrupciones. Una caché bien diseñada es lo que entrega experiencias de usuario rápidas sin bugs de obsolescencia silenciosa. Cuantifica el coste total a lo largo de la vida del sistema. Una arquitectura de datos bien elegida evita el coste recurrente de trabajar en torno a una deficiente, y un solo incidente de corrupción de datos evitado suele superar con creces todo el coste de hacer las cosas bien. En sectores regulados, la capacidad de demostrar la integridad y la residencia de los datos no es un centro de coste, sino una licencia para operar.

Antipatrónes y trampas

Base de datos compartida entre servicios. Varios servicios leyendo y escribiendo en un mismo esquema, acoplando equipos y convirtiendo cada cambio en una crisis de coordinación.
Una sola base de datos para todo. Forzar analítica, colas, búsqueda y transacciones sobre un único motor relacional hasta que colapse.
Migraciones de un solo golpe. Cambios destructivos de esquema que exigen interrupción y no permiten un rollback seguro.
Caché sin estrategia de invalidación. Datos obsoletos servidos indefinidamente, o bugs de corrección porque nadie es dueño de cuándo se limpia la caché.
Fragmentación prematura. Distribuir los datos antes de que la carga lo exija, perdiendo de forma permanente joins y transacciones sin beneficio.
Ignorar el desfase de replicación. Leer la propia escritura desde una réplica con retraso y obtener datos obsoletos, rompiendo las expectativas del usuario.
Crecimiento ilimitado de datos. Sin estrategia de archivo ni retención, de modo que las tablas crecen hasta que rendimiento y coste se vuelven insostenibles.
Tratar los datos derivados como verdad. Tomar una caché, un índice o una proyección como sistema de registro y descubrir después que se ha desviado.

Modelo de madurez

Nivel 1: Inicia. Una sola base de datos se usa para todo. Los cambios de esquema son manuales y ad hoc, sin disciplina de migración. La caché es incidental y la invalidación se deja al azar. Los problemas de rendimiento se resuelven reactivamente comprando un servidor más potente, y nadie puede nombrar con fiabilidad el sistema de registro de un dado conjunto de datos.
Nivel 2: En desarrollo. Algunas decisiones de almacenamiento son deliberadas y ha aparecido una caché o un warehouse, pero la práctica varía entre equipos. Las migraciones están versionadas, pero a veces exigen interrupción, y la expansión-contracción se usa solo por quien la conoce. Varios servicios siguen compartiendo una base de datos, y las estrategias de caché difieren de un equipo a otro.
Nivel 3: Estandarizado. La persistencia políglota se ajusta a los casos de uso, cada almacén es propiedad de un servicio y nunca se comparte. Las migraciones automatizadas, compatibles hacia atrás y sin interrupción mediante expansión-contracción son el estándar documentado y aplicado en toda la organización. Las estrategias de caché, los TTL y las rutas de invalidación son artefactos de diseño explícitos, y el sistema de registro único de cada conjunto de datos está documentado, con todas las copias derivadas reconstruibles a partir de él.
Nivel 4: Gestionado. La infraestructura de datos se mide y controla frente a baselines. Se registra la duración y la tasa de rollback de las migraciones, el desfase de replicación frente a los requisitos de read-your-writes, la tasa de acierto de caché y los incidentes de obsolescencia, el coste operativo por almacén y la latencia de consulta en los percentiles objetivo, y se actúa sobre los números. La retención y la residencia se audit frente a los requisitos normativos, la corrección de los datos derivados se verifica de forma continua, y cada motor debe justificar su coste frente al caso de uso que sirve.
Nivel 5: Orquestado. La arquitectura de datos se mejora de forma continua e integra con la planificación de capacidad, coste y riesgo a nivel de organización. Las decisiones de fragmentación, caché y consistencia se reequilibran por caso de uso a medida que los patrones de acceso y el coste cambian, y los almacenes que ya no justifican su lugar se retiran mediante migraciones planificadas. La evolución del esquema, el archivo y la residencia están plenamente automatizados y adaptativos, de modo que la infraestructura se reconfigura ante nuevos requerimientos y cargas sin replataformas de emergencia.

Ideas para el debate

¿Cuál de tus almacenes actuales hace un trabajo para el que no fue diseñado, y cuál sería el motor adecuado?
¿Puedes realizar un cambio de esquema en tu tabla más grande hoy sin interrupción? Si no, ¿por qué?
¿Dónde tu sistema caches datos cuya obsolescencia podría causar un fallo de cumplimiento o de corrección?
¿Qué servicios comparten una base de datos, y qué haría falta para que cada uno tuviera la suya?
¿Dónde una base de datos de escritura única es tu techo de escala, y es la replicación de lectura o la fragmentación el siguiente paso correcto?
¿Cuál es tu estrategia de retención y archivo, y quién es el responsable?

Ideas clave

Los datos perduran más que el código; las decisiones de almacenamiento y modelado condicionan al negocio durante toda la vida útil del sistema.
Ajusta cada caso de uso al paradigma de almacenamiento que le conviene; espera la persistencia políglota a gran escala.
Asigna a cada servicio la propiedad de sus datos; nunca acoples equipos a través de una base de datos compartida.
Trata la evolución del esquema como un proceso continuo y aplica migraciones de expansión-contracción compatibles hacia atrás y sin interrupción.
La caché es un problema de corrección: diseña los TTL, la invalidación y la protección contra avalanchas con deliberación, y nunca caches datos críticos para el cumplimiento sin una ruta de invalidación probada.
Adquiere solo la consistencia y las garantías transaccionales que cada caso de uso necesita; la fragmentación y la replicación intercambian transacciones interpartición por escala.

Referencias y lectura adicional

Martin Kleppmann, Designing Data-Intensive Applications
Pramod Sadalage y Martin Fowler, NoSQL Distilled
Pramod Sadalage y Scott Ambler, Refactoring Databases: Evolutionary Database Design
C. J. Date, An Introduction to Database Systems
Joe Celko, SQL for Smarties
Vlad Mihalcea, High-Performance Java Persistence (transacciones, aislamiento, concurrencia)
Eric Evans, Domain-Driven Design (contextos delimitados y propiedad de datos)
Werner Vogels, «Eventually Consistent»