Estilos arquitectónicos II: sistemas distribuidos

Te damos la bienvenida al Capítulo 6: Estilos arquitectónicos, segunda parte, sistemas distribuidos. El Capítulo 5 describió estilos en los que todo el sistema se despliega como una sola unidad. Este capítulo lleva las mismas preguntas a través de una red. Explica cuándo merece la pena pagar el costo de distribuir un sistema, los principales estilos distribuidos y los mecanismos de los que dependen todos ellos. Y es preciso en cuanto a los fallos, las garantías de entrega y la consistencia.

Hoy casi todo sistema de cierto tamaño está distribuido de algún modo. Una app para dispositivos móviles se comunica con servicios de backend, que llaman a proveedores de pago, servicios de mapas e intermediarios de mensajes, y los propios servicios se ejecutan en muchas máquinas. Dividir un sistema puede aportar escalado independiente, aislamiento de fallos, lanzamientos independientes y equipos autónomos. También trae problemas que no pueden darse dentro de un solo proceso: mensajes perdidos o duplicados, servicios que están lentos en lugar de caídos, datos que no coinciden entre copias y fallos en máquinas de las que no sabías que dependías.

El capítulo tiene un nivel de intermedio a avanzado. Está escrito para desarrolladores y arquitectos que diseñan o revisan sistemas formados por muchos servicios. Se apoya en los estilos del Capítulo 5 y en las cualidades del Capítulo 2, ahora en condiciones de red. En particular, usa la disponibilidad en serie y en paralelo, el acoplamiento y la ley de Conway, y el cuanto de arquitectura, el monolito modular y los contextos delimitados. Y conduce al Capítulo 7, que trata la parte más difícil de la distribución: los datos.

La idea más importante del capítulo es que distribuir es un intercambio, no una mejora. Cada beneficio se paga con latencia, consistencia, observabilidad y esfuerzo operativo. Un buen arquitecto sabe decir qué beneficio se está comprando, a qué precio y por qué no basta con una opción más barata dentro de un monolito.

El capítulo va del porqué al cómo. La sección seis punto uno expone las razones para distribuir, las ocho falacias de la computación distribuida y el fallo parcial, y te da la aritmética para poner precio al intercambio antes de comprometerte con él. La sección seis punto dos trata la arquitectura basada en servicios, un término medio pragmático de unos pocos servicios de dominio de grano grueso, y la clásica arquitectura orientada a servicios, incluido por qué cayó en desuso. La sección seis punto tres trata los microservicios: servicios alineados con contextos delimitados, despliegue independiente, una base de datos por servicio, cómo decidir el tamaño que debe tener un servicio, y el monolito distribuido. La sección seis punto cuatro trata la arquitectura dirigida por eventos: eventos y comandos, intermediarios y mediadores, garantías de entrega, y consumidores que pueden recibir sin riesgo el mismo mensaje dos veces.

Esta es la aritmética de la sección seis punto uno. Hacer un pedido pasa por cinco servicios: el API gateway y después los de pedidos, carta, precios y pagos. Cada uno espera a que responda el siguiente, y cada uno por sí solo está disponible el noventa y nueve punto nueve por ciento del tiempo. Pero las disponibilidades se multiplican. Juntos dan una ruta de solicitud de solo un noventa y nueve y medio por ciento aproximadamente: unas tres punto seis horas de inactividad al mes. Y las latencias se suman. Con veinte milisegundos de trabajo en cada servicio, más un poco por cada salto de red, la mediana es de unos ciento diez milisegundos. Cinco servicios respetables por separado han producido una ruta de solicitud mucho más débil. Ese es el precio de la distribución, calculado sobre el papel antes de construir nada.

Este diagrama muestra el fallo parcial, el problema definitorio. Un servicio de pedidos pide a un servicio de pagos que autorice veinticuatro libras con cincuenta, y espera la respuesta. Pueden salir mal tres cosas distintas. La solicitud se pierde, y no se hizo ningún cargo. El servicio de pagos se cae o se bloquea, y nadie lo sabe. O se pierde la respuesta, y la tarjeta sí recibió el cargo. Para quien llama, las tres parecen idénticas: no llega respuesta antes del timeout. Así que toda operación que pueda reintentarse debe ser idempotente, lo que significa que hacerla dos veces tiene el mismo efecto que hacerla una.

La segunda mitad pasa a los mecanismos de los que depende todo estilo distribuido. La sección seis punto cinco compara la comunicación síncrona y la asíncrona y el acoplamiento que crea cada una, y trata el diseño de API, el versionado y las pruebas de contrato. La sección seis punto seis trata lo que pueden esperar quienes leen datos copiados: los modelos de consistencia, lo que dice realmente el teorema CAP, y PACELC. La sección seis punto siete explica por qué se evita la confirmación en dos fases entre servicios, y cómo las sagas, las transacciones compensatorias y el patrón outbox mantienen correctos los procesos de negocio sin ella. La sección seis punto ocho cierra con dos estilos para perfiles de carga particulares: las funciones serverless, que escalan hasta cero, y la arquitectura basada en espacios, que mantiene los datos en memoria para sobrevivir a picos extremos, como la puesta a la venta de entradas.

Tres hábitos recorren todas las secciones. Primero, cuenta las dependencias síncronas, no los servicios. El número de cosas que deben funcionar todas en el mismo momento para que una solicitud tenga éxito decide su disponibilidad y su latencia. Segundo, da por hecho que los mensajes se pierden, se retrasan, se duplican y llegan desordenados, y diseña los receptores para que un mensaje repetido no cause daño. Tercero, decide quién es el propietario de cada dato, porque la propiedad decide dónde son posibles las transacciones y dónde hay que gestionar la consistencia entre servicios. El Capítulo 7 desarrolla ese hábito en un tratamiento completo de la arquitectura de datos.

Si el tema es nuevo para ti, lee primero el resumen inicial de cada sección y los recuadros titulados Si eres nuevo en esto. Los ingenieros con experiencia encontrarán precisión donde importa. El capítulo se lee en unas tres horas y media. Hay dos ejemplos que se repiten. La plataforma de reparto de comida muestra el diseño distribuido corriente. Un sistema de venta de entradas para una gira por estadios muestra lo que cambia cuando decenas de miles de personas quieren los mismos pocos asientos en el mismo segundo. Cada sección termina con unas cuantas preguntas de autoevaluación. Respóndelas mentalmente antes de mirar. Cuando estés listo, haz la prueba opcional del capítulo: veinte preguntas de opción múltiple y dos respuestas escritas, en unos cuarenta y cinco minutos. La nota de aprobado es el ochenta por ciento.

Ese es el mapa del Capítulo 6. Empieza por la sección seis punto uno, donde sopesamos las razones para distribuir frente a las falacias que lo hacen más difícil de lo que parece. Nos vemos allí.