Propiedad de los datos y base de datos por servicio

Por qué la propiedad es la primera pregunta sobre los datos

El Capítulo 6 dividió los sistemas en servicios que se despliegan, se escalan y se cambian de forma independiente. El código se divide con relativa facilidad; los datos, no. Un pedido hace referencia a un cliente, un plato de la carta, un restaurante y un repartidor, y cada equipo quiere leer, y a menudo cambiar, alguna parte de él. Por eso, la pregunta más importante en una arquitectura de datos distribuida no es qué base de datos comprar, sino quién es el propietario de cada dato: qué componente puede cambiarlo, cuál aplica sus reglas y cómo llegan a verlo todos los demás.

La propiedad importa porque los datos sobreviven al código. Los servicios se reescriben cada pocos años; las cuentas de clientes, los libros mayores y los historiales médicos se conservan durante décadas. Equivocarse con la propiedad produce el tipo caro de deuda arquitectónica: dos servicios que no pueden lanzarse por separado porque comparten tablas, un campo de estado que tres equipos sobrescriben por turnos, o un informe mensual que nadie puede reproducir porque las cifras salen de cinco copias de los mismos datos que no coinciden.

Esta sección usa dos ejemplos recurrentes que vuelven a aparecer a lo largo del capítulo: una plataforma de reparto de comida (clientes, restaurantes, repartidores, pedidos) y un banco en línea (clientes, cuentas, pagos, un libro mayor).

Sistema de registro y propiedad de los datos

Un sistema de registro es la fuente autorizada de un dato concreto: el lugar cuyo valor prevalece cuando las copias no coinciden. En el banco, el libro mayor central es el sistema de registro de los saldos de las cuentas; el saldo que se muestra en la app para dispositivos móviles, el que está en la caché del motor de fraude y el de la carga de anoche en el almacén de datos son todos copias. En la plataforma de reparto de comida, el propio servicio de cartas del restaurante es el sistema de registro de los precios, aunque el índice de búsqueda, la caché sin conexión de la app para dispositivos móviles y las líneas de pedido contengan copias de ellos.

La propiedad de los datos convierte esto en una responsabilidad. El componente propietario (y el equipo que hay detrás) es el único que escribe los datos, aplica sus invariantes (reglas que deben cumplirse siempre, como un asiento del libro mayor nunca se edita, solo se revierte), decide su esquema y los publica para los demás a través de una interfaz que controla. La propiedad es una decisión de diseño, no una propiedad de la base de datos: dos servicios pueden estar en el mismo servidor de base de datos y tener aun así una propiedad clara, y dos servicios con bases de datos separadas pueden seguir peleándose por los mismos hechos si el límite entre ellos está mal trazado.

Una regla útil de Software Architecture: The Hard Parts (Neal Ford, Mark Richards, Pramod Sadalage y Zhamak Dehghani, 2021) es que el servicio que escribe en una tabla es su propietario. Compartir la lectura es barato; compartir la escritura no lo es, porque quien escribe debe aplicar las reglas.

La base de datos compartida y por qué acopla los servicios

La forma más sencilla de permitir que varias aplicaciones trabajen con los mismos datos es darles a todas acceso a una única base de datos. Martin Fowler la llamó base de datos de integración (2004): una base de datos que es el punto de integración entre aplicaciones, a diferencia de una base de datos de aplicación, que sirve a una sola aplicación. Parece atractiva: no hay que construir API, los joins funcionan sobre todo y una sola transacción puede actualizar a la vez pedidos y pagos. El veredicto de Fowler, que comparte la mayoría de los arquitectos, es que las bases de datos de integración deben evitarse, porque el acoplamiento que crean es profundo y en gran parte invisible.

Piensa en las formas de acoplamiento que introduce. Acoplamiento de esquema: cada tabla y cada columna es, en la práctica, una API pública. Renombrar orders.state como orders.status rompe cualquier servicio que la lea, y nadie puede estar seguro de cuáles lo hacen, porque las consultas SQL están dispersas por muchas bases de código, informes y hojas de cálculo. Acoplamiento de despliegue: un cambio de esquema tiene que coordinarse entre todos los equipos que tocan la tabla, así que servicios que debían lanzarse de forma independiente se lanzan juntos. Acoplamiento semántico: el esquema debe servir a todos los clientes, así que se vuelve más general y más confuso (Fowler señala que acaba intentando unificar conceptos que pertenecen a contextos delimitados distintos), y las reglas de negocio de una tabla acaban duplicadas, de forma incoherente, en cada servicio que escribe en ella. Acoplamiento en tiempo de ejecución: la consulta lenta de un informe o el proceso por lotes con muchos bloqueos de un servicio degrada a todos los demás, y la base de datos se convierte en un punto único de fallo compartido y en un techo para las conexiones.

Nada de esto es fatal para una sola aplicación o para un monolito modular cuyos módulos respetan las tablas de los demás, ni para la arquitectura basada en servicios de grano grueso, en la que un puñado de servicios de dominio suele compartir una base de datos de forma deliberada. Se convierte en un problema cuando los equipos esperan desplegabilidad independiente pero mantienen las tablas compartidas, que es una vía clásica hacia un monolito distribuido.

Base de datos por servicio

La alternativa, asociada a los microservicios, es el patrón de base de datos por servicio: los datos persistentes de cada servicio son privados y los demás servicios solo pueden acceder a ellos a través de la API del servicio o de los eventos que publica. El catálogo de patrones de Chris Richardson (microservices.io) señala que esto no tiene por qué significar un servidor distinto por servicio. Hay tres niveles de separación, y la línea importante es la primera.

Los beneficios son el reflejo de los costos de la base de datos compartida: los propietarios cambian sus esquemas libremente, escalan y ajustan sus almacenes de forma independiente, eligen el tipo de base de datos adecuado y contienen los fallos. Los costos son reales y deben constar en cualquier registro de decisión. Los joins entre servicios desaparecen y deben sustituirse por composición de API o datos replicados. Una sola transacción ACID ya no puede abarcar pedidos y pagos; los cambios entre servicios se convierten en sagas con pasos compensatorios. La integridad referencial entre servicios (todo pedido apunta a un cliente real) ya no la garantizan las claves foráneas. Los informes necesitan un pipeline aparte. Y hay más bases de datos que respaldar, parchear y monitorizar.

The Hard Parts plantea la decisión como un equilibrio de fuerzas. Los desintegradores empujan hacia la división de los datos: el control de cambios (cuántos servicios se rompen cuando cambia una tabla), los límites de conexiones, la escalabilidad, la tolerancia a fallos, el deseo de tener unidades desplegables de forma independiente y la necesidad de distintos tipos de base de datos. Los integradores tiran de los datos para mantenerlos juntos: las relaciones que necesitan integridad referencial y las operaciones que de verdad necesitan una única transacción atómica. Si dos tablas siempre se cambian juntas en una transacción y no tienen vida independiente, eso es una prueba sólida de que pertenecen al mismo propietario.

Cuando varios servicios escriben los mismos datos

Las preguntas sobre la propiedad se vuelven difíciles cuando más de un servicio cambia legítimamente la misma entidad. The Hard Parts distingue tres situaciones. Con la propiedad única, solo un servicio escribe en la tabla y es, sin más, su propietario. Con la propiedad común, la mayoría de los servicios escriben en la misma tabla (un registro de auditoría o un conjunto de parámetros de configuración, por ejemplo); la respuesta habitual es crear un servicio dedicado que sea el propietario de los datos y dar a todos los demás una API, a menudo asíncrona para no ralentizar a quienes escriben. Con la propiedad conjunta, un número pequeño de servicios, normalmente dos, escribe en la misma tabla, por lo general dentro del mismo dominio. El libro ofrece cuatro técnicas para la propiedad conjunta.

Ninguna técnica es gratuita, y la adecuada depende de con qué frecuencia cambian los datos, de cuán estrictas son sus reglas y de cuán independientes necesitan ser los equipos. En la práctica, delegar es la respuesta más habitual para las entidades de negocio con un ciclo de vida (pedidos, pagos, reservas), la división de la tabla funciona bien cuando las columnas escritas conjuntamente son en realidad hechos distintos que casualmente se almacenaban juntos, y la consolidación es la respuesta honesta cuando los dos servicios se dividieron con un grano demasiado fino desde el principio.

Leer datos de los que no eres propietario

Una vez resuelta la propiedad, todos los demás servicios siguen necesitando leer los datos. La pantalla de cocina necesita las notas de entrega del cliente; el motor de fraude necesita los pagos recientes de la cuenta. Hay cuatro grandes opciones, y cada una intercambia frescura por acoplamiento. Ten en cuenta que los diseños dirigidos por eventos, tratados en el Capítulo 6, proporcionan la tercera y la cuarta.

Fowler llama a la cuarta opción transferencia de estado transportada por eventos: eventos como MenuItemPriceChanged transportan los nuevos valores, así que los consumidores no necesitan volver a llamar. Un mecanismo relacionado, la captura de datos de cambios (CDC), lee el log de la base de datos del propietario y convierte cada cambio confirmado en un evento, lo que evita el problema de la escritura dual (escribir en la base de datos y publicar un evento por separado, de modo que una operación puede tener éxito mientras la otra falla). La bandeja de salida transaccional (transactional outbox), que resuelve el mismo problema desde dentro de la aplicación, se trata junto con las sagas.

Informes que abarcan varios servicios

La base de datos por servicio complica una tarea antigua: el informe transversal. Ingresos por restaurante y por semana, descontando los reembolsos, desglosados por tipo de repartidor necesita pedidos, pagos, restaurantes y entregas. Generarlo llamando a cuatro API página a página es lento y carga a los servicios operativos con el trabajo de los informes. Consultar directamente sus bases de datos reintroduce por la puerta de atrás el acoplamiento de la base de datos compartida.

La respuesta habitual es separar los informes de las operaciones. Fowler describió una base de datos de informes: un almacén separado, con una forma pensada para las consultas y alimentado desde los sistemas operativos, que los usuarios de informes pueden leer libremente. Hoy suele ser un almacén de datos o un lakehouse alimentado por CDC o por eventos, que se trata en analítica y streaming. Para vistas pequeñas y casi en tiempo real dentro del producto (el panel de los pedidos del día de un restaurante), un servicio puede construir su propio modelo de lectura a partir de eventos, la idea que hay detrás de CQRS. En cualquier caso, los pipelines que alimentan los informes dependen de las estructuras de datos de los propietarios, y por eso necesitan contratos.

Contratos de datos

Un contrato de datos es un acuerdo explícito y versionado entre el propietario de un conjunto de datos y sus consumidores. Establece el esquema (campos, tipos, cuáles pueden ser nulos), el significado de cada campo (¿amount está en peniques o en libras, con IVA o sin él?), las expectativas de calidad (ningún identificador de pedido duplicado, como máximo un 0.1% de filas sin restaurante), los niveles de servicio (cuán frescos son los datos, cuánto tiempo se conservan), quién es su propietario y cómo se anuncian los cambios. Aplica la idea de un contrato de API a los datos que circulan entre equipos mediante eventos, flujos de CDC y tablas del almacén de datos.

Los contratos son más útiles cuando son legibles por máquina y se comprueban automáticamente: un pipeline que rechaza un cambio de esquema que rompería a los consumidores registrados, o una prueba que falla cuando se incumple una regla de calidad. El Open Data Contract Standard (ODCS), mantenido por el proyecto Bitol bajo la Linux Foundation AI & Data, define un formato YAML que abarca el esquema, las reglas de calidad, los niveles de servicio, los roles y los canales de soporte. Los contratos de datos no son gratuitos: alguien tiene que escribirlos y mantenerlos, y los contratos demasiado estrictos frenan el cambio. The Hard Parts contrapone los contratos estrictos (precisos, verificables, con un acoplamiento fuerte) a los flexibles (más fáciles de hacer evolucionar, pero que necesitan más pruebas), y propone como término medio los contratos dirigidos por el consumidor, en los que los consumidores indican lo que realmente usan. Cómo cambiar un esquema sin romper a los consumidores es el tema de evolución de esquemas.

Errores comunes

Dividir los servicios pero mantener las tablas compartidas. Los equipos cargan con el costo operativo de la distribución sin la independencia que se suponía que iba a comprar. Si los servicios no pueden desplegarse sin coordinar un cambio de esquema, no son independientes. Servicios de entidad. Un CustomerService que no es más que crear, leer, actualizar y eliminar sobre una tabla, y al que llaman todos los demás servicios, es una base de datos compartida con latencia adicional; la propiedad debe seguir a las capacidades de negocio y sus reglas, no a los sustantivos. Copias que se convierten discretamente en maestros. Consulta la advertencia anterior. Dejar los informes para el final. El primer informe financiero tras la división suele revelar que nadie planificó cómo volver a reunir los datos. Tratar la propiedad como algo puramente técnico. La propiedad también es organizativa: alguien debe responder de la calidad de los datos y, según la ley de Conway, los límites de datos que atraviesan los límites entre equipos tienden a no durar.

Una buena prueba para cualquier diseño de datos es hacerse, para cada hecho importante, tres preguntas: ¿quién es el único escritor?, ¿dónde se aplican sus reglas? y ¿cuán desactualizada puede estar cada copia? Si alguna respuesta es depende o varios servicios, el diseño no está terminado.