Apache Kafka 4.0.0 führt Share Groups als neues Konsumtionsmodell neben den traditionellen Consumer Groups ein. Share Groups verteilen einzelne Records, nicht ganze Partitionen, und bieten so eine Verteilung auf Record-Ebene für erhöhte Flexibilität. Dies unterscheidet sich von traditionellen Consumer Groups, bei denen Partitionen bestimmten Consumern zugewiesen werden, wodurch die Reihenfolge innerhalb dieser Partitionen garantiert wird. Share Groups sind ideal für volumenstarke, unabhängige Events, bei denen der Durchsatz vor der Reihenfolge priorisiert wird. Sie bieten auch Vorteile bei der dynamischen Skalierung für Workloads mit variablem Bedarf. Traditionelle Consumer Groups bleiben unerlässlich, wenn die Reihenfolge der Verarbeitung kritisch ist oder für zustandsbehaftete Verarbeitung, die eine Partitionsaffinität erfordert. In Share Groups verwaltet ein Broker-Level Share Coordinator die Record-Verteilung. Records werden von Consumern mit einem zeitbasierten Lock erworben und automatisch an den Pool zurückgegeben, wenn sie nicht innerhalb des Timeouts bestätigt werden. Consumer können Records als ACCEPT, RELEASE zum Wiederholen oder REJECT für dauerhaftes Scheitern bestätigen. Der Broker verfolgt Zustellversuche und archiviert Nachrichten automatisch nach einem konfigurierten Limit, um vor Poison Messages zu schützen. Spring for Apache Kafka 4.0.0 unterstützt Share Groups vollständig und bietet sowohl programmatische Containererstellung als auch Annotation-gesteuerte @KafkaListener-Setups. Die Konfiguration einer ShareConsumerFactory und ShareKafkaListenerContainerFactory ist erforderlich. Sowohl implizite als auch explizite Bestätigungsmodi werden unterstützt. Die implizite Bestätigung akzeptiert automatisch bei erfolgreichem Methodenabschluss und lehnt bei Ausnahmen ab, während die explizite Bestätigung eine detaillierte Steuerung mithilfe eines ShareAcknowledgment-Parameters ermöglicht. Die explizite Bestätigung erfordert jedoch, dass alle Records bestätigt werden, bevor neue Records abgefragt werden können. Share Groups ermöglichen auch die Skalierung mit Parallelität innerhalb eines einzelnen Containers, sodass mehrere Consumer-Threads Records parallel verarbeiten können.