# Broker Published articles for Broker. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Why Kafka retention.ms can delay message deletion DevFeed: [Why Kafka retention.ms can delay message deletion]() Original publisher: [Read original article]() Author: Rogerio Santos Published: 2026-09-16T13:05:06Z Content type: tutorial Language: en Sources: [Red Hat](), [Red Hat Developer]() Topics: [Kafka](), [Apache-Kafka](), [configuration](), [file](), [Event-Streaming]() Tags: [broker](), [configuration](), [diagnose](), [event-driven](), [how-to](), [kafka](), [lifecycle](), [retention](), [storage](), [stream-processing]() ### AI overview This guide explains why Kafka messages can remain readable beyond a topic's retention.ms setting. Kafka deletes closed log segments rather than individual messages, and the active segment and continuous writes can delay removal of older records. ### Source excerpt A customer opened a support case with a deceptively simple complaint: a Kafka topic was configured with a 12-hour retention (retention.ms), yet messages produced on July 24 were still readable 4 days later, on July 28. Nothing was broken. The broker logged no errors. The retention policy was working as designed, but the segment layout and continuous write pattern delayed when the old records could actually be removed. The post Why your Kafka topic ignores retention.ms (and how to fix it) appeared first on Red Hat Developer. ## We turned off Pub/Sub and nobody noticed DevFeed: [We turned off Pub/Sub and nobody noticed]() Original publisher: [Read original article]() Author: Patrick Hamann; Mike Fisher Published: 2026-08-11T13:56:40Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [event driven](), [Messaging](), [Publish-subscribe pattern](), [Availability](), [systems](), [Apache Pulsar](), [Cloud](), [Google]() Tags: [availability](), [broker](), [cloud](), [event-driven](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [messaging](), [outage](), [post-mortem](), [production](), [scale](), [slack](), [slack-incident]() ### AI overview This developer article explains how incident.io made its predominantly event-driven platform more resilient by adding a secondary message broker alongside Google Cloud Pub/Sub. It describes the role of message brokers and publish-subscribe processing, the risks of a single point of failure, and the successful production test in which Pub/Sub was turned off without affecting customers. ### Source excerpt Our entire event-driven platform ran through a single message broker, which made it a single point of failure. So we added a second one. This is the story of building an event load balancer, the queuing theory behind it, and the final chaos test where we turned off Pub/Sub in production and nobody noticed. ## Instrumenting distributed messaging: The fallacy of exactly once delivery DevFeed: [Instrumenting distributed messaging: The fallacy of exactly once delivery]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-05-17T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Kafka](), [Messaging](), [Network](), [Latency]() Tags: [architecture](), [broker](), [distributed](), [distributed-systems](), [idempotency](), [kafka](), [latency](), [messaging](), [network]() ### AI overview The article argues that exactly-once delivery cannot be guaranteed by an unreliable network's physical transport layer. It explains that Kafka's exactly-once semantics use transactional coordination, additional network round trips, and disk fsyncs, and recommends at-least-once delivery with idempotent consumers. ### Source excerpt There is no physical mechanism for exactly-once delivery over an unreliable network. If the sender does not receive an acknowledgement it can drop the message, giving at-most-once, or resend it, giving at-least-once. Those are the only two options. Kafka's exactly-once semantics buy the illusion with a transactional wrapper costing extra round trips and forced fsyncs, so configure brokers for at-least-once and make consumers fiercely idempotent instead. ## Keycloak 26.5.5 released DevFeed: [Keycloak 26.5.5 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2026-03-05T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [saml](), [Security](), [Authentication]() Tags: [2026](), [authentication](), [broker](), [cve](), [download](), [idm](), [idp](), [kerberos](), [keycloak](), [keycloak-release](), [ldap](), [login](), [migration-guide](), [openid-connect](), [release](), [saml](), [security](), [sso]() ### AI overview Keycloak 26.5.5 was released on March 5, 2026. The release includes security fixes for SAML broker authentication bypass, disabled identity provider enforcement, disabled SAML identity provider login, and encrypted assertion injection. ### Source excerpt To download the release go to Keycloak downloads. Upgrading Before upgrading refer to the migration guide for a complete list of changes. All resolved issues Security fixes #46909 CVE-2026-3047 SAML broker: Authentication bypass due to disabled SAML client completing IdP-initiated login #46910 CVE-2026-3009 Improper Enforcement of Disabled Identity Provider in IdentityBrokerService #46911 CVE-2026-2603 Disabled SAML IdP still allows IdP-initiated broker login #46912 CVE-2026-2092 saml broker encrypted assertion injection ## Lightweight MQTT Broker for ESP32: Mosquitto ported to ESP-IDF DevFeed: [Lightweight MQTT Broker for ESP32: Mosquitto ported to ESP-IDF]() Original publisher: [Read original article]() Author: John Lee Published: 2025-05-28T00:00:00Z Content type: article Language: en Sources: [Blog on Developer Portal]() Topics: [ESP32](), [MQTT](), [ESP-IDF](), [Internet of things](), [Testing](), [Home Assistant](), [P2P](), [TLS (Transport Layer Security)]() Tags: [blog](), [broker](), [edge-computing](), [esp](), [esp-idf](), [esp32](), [home-assistant](), [iot](), [mqtt](), [p2p](), [security](), [testing](), [tls]() ### AI overview This article introduces a lightweight port of the Eclipse Mosquitto MQTT broker to ESP-IDF for ESP32 devices. It describes support for TLS and TCP transports and outlines uses including private local IoT networks, on-device MQTT testing, and bridged brokers over peer-to-peer connections. ### Source excerpt Mosquitto - the industry-standard MQTT broker - has been ported to ESP-IDF. Its lightweight version retains Mosquitto's core functionality and security features to run on resource-constrained IoT devices. This MQTT broker is ideal for edge computing, testing, and standalone IoT deployments. In this article, we will do an overview and show you how to get started. ## Hacking into a Toyota/Eicher Motors insurance company by exploiting their premium calculator website DevFeed: [Hacking into a Toyota/Eicher Motors insurance company by exploiting their premium calculator website]() Original publisher: [Read original article]() Author: Eaton Published: 2024-01-17T16:25:39Z Content type: article Language: en Sources: [Eaton Works Feed]() Topics: [Hacking](), [API](), [Cloud](), [Microsoft](), [passwords](), [Authentication](), [Website]() Tags: [api](), [authentication](), [broker](), [cloud](), [hacking](), [india](), [insurance](), [microsoft](), [password]() ### AI overview A security report describes how a vulnerable API on Toyota Tsusho Insurance Broker India's premium calculator website exposed Microsoft corporate cloud credentials. The exposed account lacked two-factor authentication and contained customer emails, insurance documents, password reset links, and OTPs. Other Microsoft cloud resources were also accessible. ### Source excerpt A vulnerable API on Toyota Tsusho Insurance Broker India's premium calculator website exposed Microsoft corporate cloud credentials. ## What's New in Apache Pulsar 3.1.0 DevFeed: [What's New in Apache Pulsar 3.1.0]() Original publisher: [Read original article]() Author: tison Published: 2023-10-10T00:00:00Z Content type: release Language: en Sources: [Apache Pulsar Blog]() Topics: [Apache Pulsar](), [Compression](), [Protocol (disambiguation)](), [configuration](), [Kafka]() Tags: [apache](), [broker](), [bug-fixes](), [clusters](), [compression](), [contributors](), [customization](), [efficiency](), [feature](), [load-balancing](), [protocol](), [release](), [retention](), [storage]() ### AI overview Apache Pulsar 3.1 is a feature release shaped by more than 80 contributors and over 360 commits. The documented changes include pluggable topic compaction, customizable topic-bundle partition assignment, and a size threshold for compressing metadata. ### Source excerpt The Apache Pulsar community announces the release of Apache Pulsar 3.1, a new feature release! This is a remarkable community effort, with over 80 contributors submitting more than 360 commits for feature enhancements and bug fixes. We would like to thank all of them for their contributions! ## What's New in Apache Pulsar 2.10.4 DevFeed: [What's New in Apache Pulsar 2.10.4]() Original publisher: [Read original article]() Author: liangyepianzhou, Anonymitaet, momo-jun Published: 2023-04-19T00:00:00Z Content type: article Language: en Sources: [Apache Pulsar Blog]() Topics: [Apache Pulsar](), [releases](), [Release notes](), [Optimization](), [Concurrency]() Tags: [apache](), [broker](), [bug-fixes](), [concurrent](), [contributors](), [efficiency](), [error-handling](), [improvements](), [performance](), [releases](), [subscriptions]() ### AI overview Apache Pulsar 2.10.4 introduces improvements and bug fixes contributed through 12 commits. Highlights include better Key_Shared subscription performance, improved broker shutdown error handling, corrected cursor positioning, reduced lock contention with concurrent subscriptions, and support for deleting partitioned topics. ### Source excerpt The Apache Pulsar community releases version 2.10.4! 37 contributors provided improvements and bug fixes that delivered 12 commits. Thanks for all your contributions. ## What's New in Apache Pulsar 2.11 DevFeed: [What's New in Apache Pulsar 2.11]() Original publisher: [Read original article]() Author: Technoboy-, momo-jun Published: 2023-01-20T00:00:00Z Content type: article Language: en Sources: [Apache Pulsar Blog]() Topics: [Apache Pulsar](), [releases](), [Release notes](), [Compression](), [race-condition]() Tags: [apache](), [broker](), [community](), [compression](), [contributors](), [race-condition](), [releases]() ### AI overview Apache Pulsar 2.11 introduces feature enhancements and fixes from 61 contributors across 1,617 commits. Highlights include upgrading the server Java build version to 17, chunking with shared subscriptions, pluggable topic factories, configurable compression, metadata synchronization across clusters, and producer and consumer memory-management improvements. ### Source excerpt The Apache Pulsar community releases version 2.11! 61 contributors provided feature enhancements and fixes that delivered 1617 commits. Thanks for all your contributions. ## Kafka 的设计与实践思考 DevFeed: [Kafka 的设计与实践思考]() Original publisher: [Read original article]() Author: Joway Published: 2018-04-16T00:00:00Z Content type: tutorial Language: zh Sources: [Random Thoughts]() Topics: [Kafka](), [Replication](), [data]() Tags: [api](), [broker](), [data](), [file](), [index](), [kafka](), [leader](), [partition](), [replication](), [sync](), [tech](), [zookeeper]() ### AI overview A Chinese-language technical article presents a personal summary of Kafka's architecture, internal components, storage design, and APIs. It explains the roles of ZooKeeper, brokers, partitions, replication, leaders, ISR, offsets, segments, sparse indexes, and message access. ### Source excerpt 前几天看了 librdkafka 的官方文档，这篇文档不仅仅讲解了如何使用 Kafka ，某种程度也讲解了分布式系统实现的难点和使用细节，故而让我对 Kafka 的实现原理产生了浓厚的兴趣。 这篇文章从 Kafka 的设计到使用做了一些个人总结，围绕真正实践场景，探寻其设计上的智慧与妥协。 设计 架构设计 Zookeeper Zookeeper 存储了 Kafka 集群状态信息 。 Zookeeper 还负责从 Broker 中选举出一个机器作为 Controller, 并确保其唯一性。 同时, 当 Controller 宕机时, 再选举一个新的 。 ## Kafka, a walking skeleton DevFeed: [Kafka, a walking skeleton]() Original publisher: [Read original article]() Author: brice.dutheil@gmail.com (Brice Dutheil) Published: 2017-04-29T00:00:00Z Content type: article Language: fr Sources: [The Coffee Workshop]() Topics: [Kafka](), [Open Source](), [Publish-subscribe pattern](), [Hadoop]() Tags: [article](), [blog-post](), [broker](), [kafka](), [messages](), [open-source](), [performance](), [production](), [queuing]() ### AI overview This French article introduces Apache Kafka through a minimal end-to-end implementation, based on Kafka 0.9. It explains Kafka's origins at LinkedIn and describes its performance, durable message retention, scalability, fault resilience, and support for queuing and publish-subscribe messaging. ### Source excerpt Ce blog post est une republication de mon article sur Kafka parut dans le magazine Programmez numéro 196 en mai 2016 (pages 70-73). Il se base sur la version 0.9 de Kafka. ## Disque: A Message Broker Designed for Reliable Message Delivery DevFeed: [Disque: A Message Broker Designed for Reliable Message Delivery]() Original publisher: [Read original article]() Published: 2015-03-15T22:32:15Z Content type: article Language: en Sources: [Antirez]() Topics: [Redis]() Tags: [blog](), [broker](), [message-queue](), [queue](), [redis]() ### AI overview The article introduces Disque, an in-development message broker, and explains why developers often use Redis as a message queue. It discusses the differences between Redis data structures and immutable messages, along with at-most-once and at-least-once delivery semantics. ### Source excerpt EDIT: In case you missed it, Disque source code is now available at http://github.com/antirez/disque It is a few months that I spend ~ 15-20% of my time, mostly hours stolen to nights and weekends, working to a new system. It's a message broker and it's called Disque. I've an implementation of 80% of what was in the original specification, but still I don't feel like it's ready to be released. Since I can't ship, I'll at least blog... so that's the story of how it started and a few details about what it is. ~ First steps ~ Many developers use Redis as a message queue, often wrappered via some library abstracting away Redis low level primitives, other times directly building a simple, ad-hoc queue, using the Redis raw API. This use case is covered mainly using blocking list operations, and list push operations. Redis apparently is at the same time the best and the worst system to use like that. It's good because it is fast, easy to inspect, deploy and use, and in many environments it was already one piece of the infrastructure. However it has disadvantages because Redis mutable data structures are very different than immutable messages. Redis HA / Cluster tradeoffs are totally biased towards large mutable values, but the same tradeoffs are not the best ones to deal with messages. One thing that is important to guarantee for a message broker is that a message is delivered either at least one time, or at most one time. In short given that to guarantee an exact single delivery of a message (where for delivery we intent a message that was received *and* processed by a worker) is practically impossible, the choices are that the message broker is able to guarantee either 0 or 1 deliveries, or 1 to infinite deliveries. This is often referred as at-most-once semantics, and at-least-once semantics. There are use cases for the first, but the most interesting and practical semantics is the latter, that is, to guarantee that a message is delivered at least one time, and deliver mu