#42416 no veo como tener la solucion mas simple de un evento por topic, donde aplanas todos los eventos a 1on1, donde puedes delegar al broker la mayoria de funcionalidades de garantizar delivery, retries, reliability, balanceado, es añadir overhead.
sin habermelo mirado supongo que la diferencia con rabbit o el broker amqp que sea sera capacitar routing dinamico vs statico en el broker. donde el estatico siempre sera mas eficiente y tendra mas propiedades garantizadas porque el propio broker lo implementa por ti. y voy a suponer que los algoritmos del broker y el codigo es mas eficiente y tiene mejor rendimiento que tu codigo. que como minimo, debera serializar los mensajes en memoria...
deberiamos ver que headers y funcionalidades con metadatos permite el broker para realizar agregados, filtrados, reducers o aplanados (fans in o fans out) para acabar de comparar la complejidad... porque siempre que el broker lo haga por ti sera mas simple, facil y eficiente que si lo programas tu a mano. y esto depende del broker que uses. kafka vs rabbit vs redis...
deberias pensar porque necesitas tener un routing dinamico con las keys, y que significa generar nueva infra. porque meter un topic a un broker no deberia ser ningun problema. y si tienes que migrar o realizar cambios con topics en runtime en ambas situaciones tendiras que realizar una migracion de topics. te da igual si es un topic o un header. la diferencia con un topic es que en casos de estar haciendo pruebas no tienes inconvinientes... pero el dia que llegue a prod ya te dara igual.
luego otro tema seria el de observabilidad y provisionamiento. al menos con kafka y similares escalamos por consumer groups que van asociados a topics. si un evento es mas costoso de procesar, se utilizan los metadatos del broker como el tiempo de consumo de topic o elementos en cola para realizar escalados. si todo esto lo haces con un topic generico no sabes que tipo de eventos tienes ni como son, de nuevo. vas a tener que implementarlo todo tu a mano... lo bueno es que el broker lo haga por ti y tu solo tengas que provisionar o meter reglas de escalado basado en metricas. si publicas 10 eventos a 1 un topic generico, y los 10 eventos se consumen por servicios distintos, que tienen requerimientos de CPU y MEM distintos, como provisionas?
utilizar colas genericas es como usar HTTP donde todo es POST, no utilizas GET ni PUT ni PATCH ni DELETE... todo es un POST donde dentro el body decides la logica y tu consumer se encarga de despatch... veo pocos casos donde esto valga la pena a no ser que usar una routing key sea x100 mas rapido y eficiente vs usar un topic. que lo dudo. ya que como digo la diferencia deberia ser un tema de enrutamiento a nivel interno del broker.
me estas diciendo que usar un HTTP solo con POST, donde solo tienes 1 endpoint de entrada a tu aplicacion. tiene menos complejidad y overhead que usar todas las herramientas que HTTP te proporciona. no lo veo claro... por otro lado, si en lugar de HTTP estas tirando TCP a pelo con tu propio protocolo (broker) y es super eficiente o esta optimizado para tu caso de uso lo podria entender. pero entonces deberias estar trabajando en un broker mas que en aplicarlo como usuario...
añado que yo trabajo con cosas managed y quizas lo que para mi es añadir una linea para crear un topic de kafak, en la practica, requiere mucho mas trabajo. pero bueno, incluso si lo tuviese que hacer a mano no veo que sea un con enorme. a no ser que estuviese haciendo una demo o un mvp... si va a ir a prod me va a dar muchos mas beneficios hacerlo bien desde el principio.
el tema del schema del topic entonces como funciona si usas routing keys? porque el tema de la serializacion y el schema versioning tambien debe ser mas complejo y jodido.
otro ejemplo sobre HTTP, seria router en aplicacion vs network. lo comentaba antes. mucho mas rapido y eficiente router por el path o por headers, que no tener que parsear el body de una request... si utilizas colas te vas a encontrar el mismo problema con los headers vs el body de los eventos. si queires filtrar o enrutar segun propiedades es mejor tener headers. que ahi es donde entiendo que entran las routing_keys. por ejemplo para tener el trafico separado por tenant en entornos multi-tenant.. como los tenants son dinamicos no tiene sentido tenerlo estatico en el topic... y yo supongo que me estas hablando de tener topics para casos de uso que necesitan procesarse. como por ejemplo realizar trabajas en batch periodicos.
no soy indepe
