Capítulo 1. Un caso (de libro) de coherencia final

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Dra. Denise Koessler Gosnell

Considera la vida de propietario de una librería.1 En algún momento, querrás establecer un sistema que mantenga un inventario de todos los libros de tu tienda.

En los inicios de la tienda, seleccionaste un sistema diseñado para unos 1.000 libros en un solo local. Este sistema actualiza el registro de un libro durante la compra de un cliente. Cuando un cliente se acerca al mostrador para comprar un libro, tu sistema de inventario hace lo siguiente:

  1. Comprueba los detalles del inventario en tus libros de contabilidad

  2. Registra la nueva compra

  3. Actualiza todos los registros

  4. Devuelve un recibo al cliente

El recibo confirma tanto la compra del cliente como que tu sistema de inventario está actualizado. Este tipo de sistema de inventario requiere que todas tus transacciones tengan una fuerte consistencia. En este sentido, la consistencia fuerte se refiere a que todos los accesos al inventario de la tienda se procesen secuencialmente y se lean desde el mismo estado en el sistema de inventario de tu tienda.

Buenas noticias, ¡propietario de una tienda! El negocio de los libros está en auge y estás abriendo varias tiendas para atender a tu creciente clientela. En este mundo, ¿cómo mantienes el inventario de tu empresa en varias tiendas?

Quizá te plantees rediseñar tu sistema actual. Decides tener una caja registradora maestra en tu primera tienda. Luego, todas tus demás tiendas tendrán un nuevo registro que se conecte al maestro.

Este nuevo sistema funciona de maravilla... hasta que pierdes la alimentación de tu caja registradora principal. Ahora todos los clientes de todas tus tiendas están bloqueados para hacer una sola compra. Tus colas son largas y están estancadas.

¿Vas a dejar que tus clientes se marchen frustrados cuando tu cola tarde demasiado en procesarse? Para resolver esto, quizá decidas que validar y actualizar el inventario de tu tienda puede hacerse de otra manera.

Quizá esta vez te plantees actualizar tus libros de contabilidad diariamente. En este nuevo sistema, al cierre nocturno, actualizas el inventario de tus libros contando todos los que hay en cada tienda y validando que cada título que esperas está en tus estanterías. Cada noche, las estanterías de tus tiendas pasan las pruebas, y puedes irte a casa con la seguridad de que tus libros están equilibrados.

Este segundo tipo de sistema de inventario prevé que todas tus transacciones tengan una coherencia final. Cada acceso al inventario de tu tienda se procesa en paralelo y registra una actualización en el sistema de inventario de tu libro. Finalmente, todos los accesos sobre un libro concreto devolverán el último valor actualizado.

¿Y qué ocurre si un cliente va a buscar un título que no está en tus estanterías? Bueno, entonces puedes abordarlo.

Abordar las incoherencias cuando se encuentran es como reparar la lectura en un sistema distribuido. Sólo cuando encuentras una incoherencia inicias el proceso más pesado para actualizar el estado en todos tus libros mayores. Durante este proceso, puedes inspeccionar tus registros de ventas para comprobar si los registros están actualizados. El resultado de estas múltiples inspecciones del estado es garantizar que tus registros están actualizados y son coherentes.

¿Te basta con este proceso? Para los sistemas que tienen que cambiar el procesamiento de grandes volúmenes por la coherencia del estado, sí.

Cambiar a un sistema eventualmente consistente con reparación de lectura para solucionar las incoherencias evitará a tus clientes el peligro de las largas colas en la caja registradora. Y hará que tus arquitectos se sientan menos estresados por proteger la disponibilidad de la base de datos de tu caja registradora maestra.

En términos generales, los dos enfoques para mantener el inventario en tu tienda representan dos escuelas de pensamiento. Describen dos arquitecturas diferentes: una que es fuertemente consistente (abordando la escala con arquitecturas de tipo cliente/servidor) y otra que es eventualmente consistente (gestionando transacciones de gran volumen y resolviendo las incoherencias de estado cuando se encuentran).

Entonces, para el sistema que estás diseñando, ¿con qué escuela de pensamiento quieres planificar?

1 Denise Gosnell agradece a David Bechberger sus aportaciones a este capítulo.

Get 97 cosas que todo ingeniero de datos debe saber now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.