{"id":184852,"date":"2026-03-04T12:33:29","date_gmt":"2026-03-04T11:33:29","guid":{"rendered":"https:\/\/liora.io\/es\/kafka-finalmente-incorpora-queues-por-que-esto-lo-cambia-todo"},"modified":"2026-03-04T12:33:29","modified_gmt":"2026-03-04T11:33:29","slug":"kafka-finalmente-incorpora-queues-por-que-esto-lo-cambia-todo","status":"publish","type":"post","link":"https:\/\/liora.io\/es\/kafka-finalmente-incorpora-queues-por-que-esto-lo-cambia-todo","title":{"rendered":"Kafka finalmente incorpora Queues: por qu\u00e9 esto lo cambia todo"},"content":{"rendered":"

Confluent ha lanzado \u00abQueues for Kafka\u00bb, una nueva funcionalidad que dota a la plataforma de streaming Apache Kafka de capacidades tradicionales de colas de mensajes, permitiendo a las organizaciones gestionar cargas de trabajo tanto de streaming como de colas en un \u00fanico sistema. Esta caracter\u00edstica, ya disponible en Confluent Cloud y Confluent Platform 7.7, introduce los \u00abshare groups\u00bb, que permiten a m\u00faltiples consumidores procesar mensajes de la misma partici\u00f3n simult\u00e1neamente, lo cual supone un cambio significativo respecto al modelo tradicional de Kafka de un solo consumidor por partici\u00f3n.<\/strong><\/p>\n

Este desarrollo representa un giro fundamental para Apache Kafka<\/strong>, que tradicionalmente ha requerido que cada partici\u00f3n sea procesada por un \u00fanico consumidor de forma simult\u00e1nea. La nueva capacidad, basada en KIP-932<\/strong> e incluida en el lanzamiento principal de Apache Kafka 4.2, permite a las organizaciones consolidar su infraestructura gestionando tanto cargas de trabajo de streaming como de colas tradicionales en una sola plataforma, seg\u00fan el anuncio de Confluent.<\/p>\n

La funcionalidad introduce el acuse de recibo por mensaje<\/strong>, sustituyendo los tradicionales commits por lotes basados en offsets de Kafka. Cuando un consumidor recupera un mensaje, el broker aplica un bloqueo de 30 segundos<\/strong> sobre el mismo, exigiendo una acci\u00f3n expl\u00edcita, como confirmar el procesamiento exitoso o liberarlo para su reenv\u00edo, explic\u00f3 Confluent en su documentaci\u00f3n t\u00e9cnica. Esto facilita el escalado el\u00e1stico<\/strong>, permitiendo ajustar el n\u00famero de consumidores independientemente del n\u00famero de particiones para gestionar cargas de trabajo variables.<\/p>\n

Compromisos t\u00e9cnicos<\/strong><\/p>\n

El cambio m\u00e1s significativo afecta al orden de los mensajes<\/strong>. Mientras que los grupos de consumidores tradicionales de Kafka garantizan el procesamiento ordenado por partici\u00f3n, los \u00abshare groups\u00bb sacrifican esta garant\u00eda para habilitar el procesamiento en paralelo, seg\u00fan indica Confluent. Los mensajes permanecen almacenados en orden, pero pueden ser procesados de forma concurrente y fuera de secuencia por m\u00faltiples consumidores. Actualmente, el sistema ofrece una sem\u00e1ntica de entrega \u00abal menos una vez\u00bb<\/strong>, con planes para integrar la sem\u00e1ntica \u00abexactamente una vez\u00bb en el futuro.<\/p>\n

Para los cl\u00fasteres Enterprise y Dedicated<\/strong> en Confluent Cloud, la funci\u00f3n est\u00e1 disponible de inmediato, mientras que el soporte para cl\u00fasteres Standard est\u00e1 previsto para la segunda mitad de 2026, declar\u00f3 la compa\u00f1\u00eda. Esta funcionalidad no conlleva ning\u00fan cargo adicional m\u00e1s all\u00e1 de los costos<\/strong> de consumo est\u00e1ndar por entrada y salida de datos y tiempo de actividad, de acuerdo con la documentaci\u00f3n de precios de Confluent.<\/p>\n

Aplicaciones de mercado<\/strong><\/p>\n

Esta caracter\u00edstica est\u00e1 orientada a cargas de trabajo operativas que se benefician de la sem\u00e1ntica tradicional de colas de mensajes, incluyendo la distribuci\u00f3n de tareas<\/strong> a grupos de trabajadores, la comunicaci\u00f3n entre servicios y el procesamiento as\u00edncrono de trabajos, se\u00f1al\u00f3 Confluent. No obstante, la compa\u00f1\u00eda recomienda los grupos de consumidores de Kafka est\u00e1ndar<\/strong> para casos de uso que requieran un orden estricto y un procesamiento por lotes de alto rendimiento, tales como el event sourcing<\/strong> y el streaming analytics<\/strong>.<\/p>\n

Confluent Cloud mejora la funcionalidad de c\u00f3digo abierto con una interfaz de usuario dedicada para gestionar los \u00abshare groups\u00bb e introduce una m\u00e9trica de \u00abshare lag\u00bb<\/strong>, similar a la profundidad de cola, que puede impulsar decisiones de autoescalado a trav\u00e9s de la API de M\u00e9tricas, seg\u00fan el blog t\u00e9cnico de la compa\u00f1\u00eda.<\/p>\n

Las futuras mejoras incluyen Dead Letter Queues<\/strong>, ordenaci\u00f3n basada en claves para restaurar ciertas garant\u00edas de orden e integraci\u00f3n con transacciones de Kafka para lograr una sem\u00e1ntica \u00abexactamente una vez\u00bb, lo que indica una inversi\u00f3n continua para convertir a Kafka en una plataforma de datos integral m\u00e1s all\u00e1 de sus or\u00edgenes en el streaming.<\/p>\n

\n

\n Sources
\n <\/h3>\n
    \n
  • Confluent<\/li>\n
  • Apache Software Foundation<\/li>\n<\/ul>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    Confluent ha lanzado \u00abQueues for Kafka\u00bb, una nueva funcionalidad que dota a la plataforma de streaming Apache Kafka de capacidades tradicionales de colas de mensajes, permitiendo a las organizaciones gestionar cargas de trabajo tanto de streaming como de colas en un \u00fanico sistema. Esta caracter\u00edstica, ya disponible en Confluent Cloud y Confluent Platform 7.7, introduce los \u00abshare groups\u00bb, que permiten a m\u00faltiples consumidores procesar mensajes de la misma partici\u00f3n simult\u00e1neamente, lo cual supone un cambio significativo respecto al modelo tradicional de Kafka de un solo consumidor por partici\u00f3n.<\/p>\n","protected":false},"author":87,"featured_media":184848,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"editor_notices":[],"footnotes":""},"categories":[2439,2428],"class_list":["post-184852","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-dev","category-noticias"],"acf":[],"_links":{"self":[{"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/posts\/184852","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/users\/87"}],"replies":[{"embeddable":true,"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/comments?post=184852"}],"version-history":[{"count":1,"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/posts\/184852\/revisions"}],"predecessor-version":[{"id":184856,"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/posts\/184852\/revisions\/184856"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/media\/184848"}],"wp:attachment":[{"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/media?parent=184852"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/liora.io\/es\/wp-json\/wp\/v2\/categories?post=184852"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}