La arquitectura orientada a eventos está pasando de ser un modelo limitado entre unos pocos servicios a convertirse en una amplia red de productores, consumidores y canales de mensajes. En este punto, el problema principal ya no es enviar el mensaje, sino saber qué se envía, quién es su propietario, quién depende de él y cómo se puede cambiar su esquema o recrear su infraestructura sin provocar fallos en producción. Este es el eje de la sesión de Ian Cooper sobre la gestión de API asíncronas a gran escala, basada en prácticas de ingeniería reales en Just Eat Takeaway.
¿Por qué se complica con la escala?
En las organizaciones pequeñas, los miembros de los equipos pueden conocer los servicios que publican y consumen eventos, y los temas o canales pueden crearse mediante el marco de mensajería o a través de una solicitud directa al equipo de la plataforma. Sin embargo, este enfoque pierde eficacia a medida que aumenta el número de equipos y servicios. Puede no estar claro quién es el propietario de un punto final determinado, qué contrato describe el mensaje o si existen consumidores desconocidos en los equipos de datos y analítica.
El riesgo aparece cuando un equipo cambia el esquema de un mensaje después de consultar únicamente a los consumidores conocidos, mientras otros equipos dependen del mensaje sin estar incluidos en el círculo de comunicación. Eliminar un tema que se considera no utilizado puede provocar la pérdida de un flujo crítico, especialmente si no existe una manera fiable de conocer a su propietario o de volver a publicar la infraestructura necesaria, salvo volver a desplegar grandes partes del sistema.
Tres ejes para gestionar las interfaces de eventos
Cooper divide el problema en descubrimiento, gobernanza y aprovisionamiento. Esto comienza por comprender qué debe describirse en cualquier punto final mediante lo que denomina los «ABC»: dirección, enlace y contrato. La dirección determina dónde fluye el mensaje, el enlace describe el protocolo, el transporte y la codificación, mientras que el contrato define las cabeceras y los datos que transporta el mensaje.
En este contexto, AsyncAPI ofrece un equivalente a los mecanismos de documentación de las interfaces HTTP, como OpenAPI, mediante el modelado de servidores, canales, mensajes, operaciones y enlaces específicos del protocolo. Admite la descripción de mensajes mediante JSON Schema, Avro y Protobuf, y también permite reutilizar definiciones en lugar de repetirlas en varios archivos. Sin embargo, Cooper subraya que colocar cientos de archivos de AsyncAPI en un único repositorio no resuelve por sí solo el descubrimiento; la búsqueda textual sigue siendo limitada cuando crece el inventario de eventos.
Por ello, las organizaciones pueden necesitar herramientas de catálogo como EventCatalog o Marmot, o un registro abierto como xRegistry, con el objetivo de mostrar los flujos de mensajes y sus relaciones, y vincular los esquemas con los productores y consumidores. Estas herramientas difieren en el nivel de visualización y en las interfaces listas para usar, pero su función común es trasladar el descubrimiento de una pregunta formulada en Slack o una búsqueda en repositorios dispersos a un servicio consultable.
El papel de CloudEvents en la unificación de los metadatos
CloudEvents aborda una parte diferente del problema, ya que proporciona un conjunto unificado de metadatos, como el identificador, el origen, la versión y el tipo, junto con campos opcionales para el tipo de contenido de los datos, el tema, la hora y el enlace al esquema. El tipo de evento puede utilizarse para enrutar el mensaje o seleccionar el mecanismo de deserialización cuando varios tipos comparten un mismo canal.
La sesión explica que los modos binary y structured de CloudEvents están relacionados con la capacidad del protocolo de transporte para transportar cabeceras, no con que el mensaje sea «binario» o «estructurado» en el sentido habitual. Este detalle es importante en sistemas como SNS, donde un número limitado de atributos del mensaje puede consumirse rápidamente si todos los datos de CloudEvents se colocan en las cabeceras, lo que hace que encapsularlos dentro del cuerpo sea una opción práctica en algunos escenarios.
La gobernanza no se limita a la documentación
Documentar el contrato informa a los consumidores sobre la naturaleza del mensaje, pero no impide que el productor publique un cambio que rompa sus dependencias. Por ello, el enfoque presentado recomienda utilizar un registro de esquemas que aplique reglas de compatibilidad al actualizar los contratos y rechace los mensajes o cambios que no cumplan las reglas aprobadas.
Las prácticas seguras suelen incluir añadir los campos como opcionales, posponer la eliminación de campos hasta que todos los consumidores hayan dejado de utilizarlos y tratar el cambio de nombre como una modificación compuesta por una eliminación y una adición. El cambio del tipo de un campo suele considerarse un cambio incompatible y puede implementarse añadiendo un campo nuevo con el tipo requerido, trasladando después los consumidores a él y eliminando finalmente el campo antiguo.
¿Qué cambia en la práctica?
El mensaje principal para el lector técnico es que la gestión de eventos a gran escala necesita una cadena interconectada, no una herramienta aislada: AsyncAPI para describir las interfaces, CloudEvents para unificar los metadatos, un catálogo o registro para facilitar el descubrimiento, un registro de esquemas para imponer la compatibilidad y automatización para aprovisionar la infraestructura y supervisar su deriva. Sin estas capas, la arquitectura orientada a eventos puede convertirse en una red de dependencias invisibles.
Siguen existiendo limitaciones prácticas: los estándares por sí solos no proporcionan un conocimiento completo de los consumidores, y las herramientas difieren en su compatibilidad con las interfaces, la visualización y la integración con los intermediarios. Por ello, aplicar este enfoque requiere establecer una propiedad clara de los contratos y canales, vincular los cambios a procesos de CI/CD y conservar una ruta de recuperación capaz de recrear los recursos, en lugar de depender del conocimiento individual o de documentación obsoleta.