Arquitectura de datos

Te damos la bienvenida al Capítulo 7, Arquitectura de datos. El código puede reescribirse en meses, pero los datos viven durante décadas. Las cuentas de clientes, los libros mayores, los pedidos y los historiales médicos sobreviven a todos los frameworks y a todos los servicios que los tocan. Mover esos datos es lento, arriesgado y caro. Por eso las decisiones de este capítulo están entre las más significativas que toma un arquitecto: son difíciles de revertir, de amplio alcance y decisivas para la disponibilidad, el rendimiento y la modificabilidad.

Este capítulo está dirigido a desarrolladores y arquitectos que ya conocen los estilos distribuidos del Capítulo 6 y que ahora necesitan tomar decisiones sólidas y defendibles sobre los datos. Se apoya directamente en el Capítulo 6. Dividir el código en servicios es la mitad fácil. En cuanto hay varios servicios, alguien tiene que decidir quién puede cambiar cada dato, cómo lo ven los demás y qué ocurre cuando sus copias no coinciden. También presupone los fundamentos de bases de datos de la sección del Capítulo 0 sobre almacenar datos. Si las tablas, las consultas y las transacciones son nuevas para ti, empieza por ahí. Y conduce al Capítulo 8, que protege estos datos y el sistema en su conjunto.

El capítulo tiene ocho secciones y sigue dos ejemplos recurrentes de principio a fin: una plataforma de reparto de comida, con su hora punta de la cena, las ubicaciones de los repartidores y las cartas, y un banco en línea, donde perder o contar dos veces un solo pago es inaceptable. La sección siete punto uno, sobre la propiedad de los datos, establece la regla más importante: todo hecho importante debe tener un único sistema de registro y un único escritor. Explica por qué una base de datos compartida acopla los servicios, por muy limpiamente que esté separado su código. La sección siete punto dos repasa los almacenes relacionales, documentales, clave-valor, de grafos, de series temporales y de otros tipos. Sostiene que la base de datos relacional sigue siendo la opción por defecto adecuada para los sistemas de registro, y que cada almacén especializado debe ganarse su lugar. La sección siete punto tres va más allá del conocido acrónimo ACID, hasta las anomalías que causa la concurrencia, como las actualizaciones perdidas y el write skew, y hasta lo que garantizan realmente los niveles de aislamiento en las bases de datos más usadas. La sección siete punto cuatro explica cómo las bases de datos copian y dividen los datos entre máquinas, qué efecto tienen el retardo de replicación y el failover sobre la corrección, y cómo elegir una clave de partición a partir de las cifras.

Esta es la primera y más importante idea del capítulo, de la sección siete punto uno. La imagen compara dos formas de dar sus datos a tres servicios. A la izquierda, los servicios de pedidos, cocina y reparto leen y escriben todos en una única base de datos compartida de pedidos, cartas y repartidores. Cualquier servicio puede cambiar cualquier tabla, así que cada tabla es una interfaz pública, y cualquier cambio de esquema requiere un lanzamiento coordinado. A la derecha, cada servicio tiene su propia base de datos. Cada esquema es privado, no hay joins entre bases de datos y los datos cruzan los límites solo mediante llamadas a la API y eventos. Ahora cada propietario puede cambiar su esquema por su cuenta. Esa independencia tiene un precio. Los joins, las transacciones y la integridad referencial entre servicios deben sustituirse por API, eventos, sagas y pipelines de informes, y la sección muestra cómo leer datos de los que no eres propietario.

La segunda mitad del capítulo trata los datos que se derivan de los sistemas de registro y el cambio a lo largo del tiempo. La sección siete punto cinco trata la segregación de responsabilidades entre comandos y consultas, o CQRS, y el event sourcing. Estos separan el modelo que acepta los cambios de los modelos que responden a las consultas, y almacenan un historial de eventos en lugar del estado actual, a un costo real en complejidad. La sección siete punto seis trata la caché: mantener copias cerca de donde se necesitan, desde el navegador hasta la base de datos, incluidas las estampidas que pueden tumbar un sistema cuando caduca una entrada popular. La sección siete punto siete acepta que todo esquema, ya sean tablas de base de datos, cargas útiles de API o eventos, cambiará mientras el sistema está en funcionamiento. Las reglas de compatibilidad y el patrón expandir y contraer permiten ese cambio sin tiempo de inactividad. Por último, la sección siete punto ocho pasa de hacer funcionar el negocio a entenderlo: almacenes de datos, lagos de datos y lakehouses, procesamiento de flujos, y el data mesh, una forma de organizar los datos analíticos en torno a los dominios.

Las secciones forman una cadena, y este diagrama de la sección siete punto dos muestra esa cadena en una plataforma de reparto de comida. Pedidos y Cartas escriben cada uno en su propia base de datos PostgreSQL. Estos son los dos únicos sistemas de registro, y contienen los pedidos, los pagos y las cartas. Todo lo demás es una copia deliberada. Las posiciones de los repartidores están en un almacén clave-valor en memoria y caducan a los treinta segundos. La captura de datos de cambios copia los cambios de las cartas en un motor de búsqueda, con unos pocos segundos de retardo. Y un almacén de datos recibe los pedidos, las cartas y una muestra de los puntos de ruta de los repartidores para la analítica, con horas de antigüedad. Cada copia es más rápida o más cómoda para algún propósito, cada una está desactualizada en cierta medida y cada una puede reconstruirse.

Esa cadena lleva a la única idea que debes llevarte de este capítulo. Para cada dato importante, deberías poder responder tres preguntas. Primera, ¿quién es su único escritor? Segunda, ¿dónde se aplican sus reglas? Y tercera, ¿cuán desactualizada puede estar cada copia? La mayoría de los problemas de datos de los sistemas reales, como pedidos que cambian de estado hacia atrás, informes que no coinciden con el libro mayor, reservas duplicadas y clientes que no pueden ver sus propios cambios, son fallos a la hora de responder deliberadamente a una de esas preguntas. Las técnicas de este capítulo son formas de responderlas bien, y cada una de ellas es un compromiso entre consistencia, disponibilidad, rendimiento, costo y el esfuerzo de operar el sistema.

Al final del capítulo, sabrás asignar la propiedad de los datos, incluidos los casos difíciles en que varios servicios quieren escribir los mismos datos. Sabrás elegir una base de datos para cada conjunto de datos, según su forma, sus patrones de acceso, sus necesidades de consistencia y su escala, y justificar el costo de cada almacén adicional. Sabrás proteger un camino de lectura, modificación y escritura con bloqueos, comprobaciones de versión o transacciones serializables. Y sabrás planificar los cambios de esquema, con reglas de compatibilidad y el patrón expandir y contraer, para que no requieran tiempo de inactividad.

Como las secciones forman una cadena, lo mejor es leerlas en orden. Pero cada una se sostiene también por sí sola, así que puedes ir directamente a la sección que necesites. Calcula unas tres horas y media para leer el capítulo entero. Al final de cada sección hay preguntas de autoevaluación. Respóndelas mentalmente antes de mirar las respuestas; te muestran rápidamente lo que se te ha quedado. Cuando estés listo, hay una prueba del capítulo opcional, que lleva unos cuarenta y cinco minutos. Tiene veinte preguntas de opción múltiple y dos respuestas escritas. La nota de aprobado es el ochenta por ciento.

Esa es la forma del capítulo. Empieza por la sección siete punto uno, sobre la propiedad de los datos y la base de datos por servicio, donde se expone en detalle la regla de un único escritor para cada hecho. Nos vemos allí.