Apache Kafka is an open source distributed event streaming platform. As the core infrastructure of real-time data pipelines, it is widely used for data integration, stream processing and AI feature transmission.

ApacheKafka

Kafka’s core parameters and statistics

Apache Kafka is the cornerstone infrastructure in the field of event streaming. It is not a native AI tool, but it provides the data pipeline required for real-time data transmission, feature engineering, and model services for AI systems. Kafka's core design revolves around "high-throughput persistent logs" - all messages are written to the disk through appending, and horizontal expansion and fault tolerance are achieved through partitioning and copy mechanisms. This architecture allows it to maintain its long-term dominance in real-time data pipeline scenarios.

Projects	Public Information
Official positioning	Distributed Event Streaming Platform
Core capabilities	High-throughput message queue, persistent log, stream processing, connector ecosystem
Deployment form	Self-hosted multi-node cluster (also supports single-node development mode)
Open Source License	Apache 2.0
Core Protocol	Kafka Wire Protocol (TCP-based binary protocol)
Ecological components	Kafka Connect, Kafka Streams, ksqlDB, Schema Registry, REST Proxy
Commercial version	Confluent Platform (enterprise self-hosted) / Confluent Cloud (fully managed SaaS)
GitHub Stars	33.3k stars / 15.4k forks / 1,390+ contributors
Community scale	One of the 5 most active projects of the Apache Software Foundation, hundreds of Meetups around the world
Latest version	3.9.x (2026-06)
Minimum Java version	Client module Java 11, server module Java 17

The value of data flow in AI: Kafka mainly plays the role of "feature transmission" and "inference event routing" in AI scenarios - synchronizing changes in data sources to feature storage or inference services in real time. Compared with traditional batch ETL, Kafka's streaming pipeline can reduce the latency from data generation to consumption from minutes to sub-seconds, which is particularly critical for online inference scenarios (recommendation, risk control, real-time pricing).

Ecological Density: Kafka Connect provides hundreds of ready-made connectors, covering mainstream systems such as databases (JDBC, Debezium CDC), cloud storage (S3, GCS), search engines (Elasticsearch), stream processing (Flink, Spark), etc. This means that Kafka’s implementation threshold depends on the maturity of the connector rather than the complexity of the infrastructure itself.

Kafka’s users and market recognition

Kafka's market recognition comes from its long-term verification in large-scale production environments, rather than public revenue figures (Confluent is a listed company, and its financial reports can indirectly reflect the commercial value of the Kafka ecosystem).

Fortune 100 Penetration: Public information on the official website shows that more than 80% of the Fortune 100 companies use Apache Kafka, covering banking (7 of the 10 largest banks), insurance (10 of the 10 largest insurance companies), energy and utilities (10 of the 10 largest companies), telecommunications (8 of the 10 largest companies), transportation (8 of the 10 largest companies), manufacturing (10 of the 10 largest companies) and other industries. This set of data reflects that Kafka has expanded from the infrastructure of Internet companies to traditional industry core systems.

GitHub community activity: 33.3k stars, 15.4k forks, 1,390+ contributors. It is one of the most active projects of the Apache Foundation. The warehouse has commits submitted from multiple sub-modules (broker, clients, streams, connect, raft) every day, indicating that project maintenance and function development are still ongoing.

Business Ecosystem: As the core commercial maintainer of Kafka, Confluent will have revenue of approximately US$900 million in 2025, and its Cloud business will grow by approximately 40% year-on-year, indicating that the enterprise-level adoption of Kafka is migrating from self-hosted to fully managed. In addition, the existence of three major hosting services, AWS MSK, Azure HDInsight Kafka, and Confluent Cloud, has significantly lowered the initial deployment threshold of Kafka.

Industry Benchmark User: LinkedIn (the birthplace of Kafka) processes more than 7 trillion messages every day; leading technology companies such as Uber, Netflix, Airbnb, and Square all use it as a core component of their data pipelines. The value of these cases does not lie in the scale numbers themselves, but in verifying Kafka's engineering maturity under extreme throughput and availability requirements.

Cost Advantages of Kafka

Kafka's cost structure is highly dependent on the deployment path and traffic scale, and there is no single "cheap/expensive" conclusion. The following compares the total cost of ownership of different solutions from three levels:

Cost dimension	Open source self-hosting	Confluent Cloud (fully managed)	Cloud vendor hosting (MSK/MSK Serverless)
License Fee	Zero (Apache 2.0)	Billed per cluster/throughput/storage	Billed per Broker instance/throughput
Infrastructure	On-premises server or cloud VM, starting from 3-9 nodes	None (SaaS delivery)	None (managed service, auto-scaling)
Operation and maintenance manpower	Requires full-time Kafka operation and maintenance or SRE team	Zero (supplier management)	Low (part of the operation and maintenance is undertaken by the cloud vendor)
Monitoring and tools	Self-built (Prometheus + Grafana + Cruise Control, etc.)	Built-in	Built-in (CloudWatch + MSK console)
Auto-scaling	Manual or self-built automation	Automatic	Manual (MSK) or automatic (MSK Serverless)
Minimum viable size	Average monthly ~$500-1,500 (3-node cloud VM + storage)	Average monthly ~$300-1,000 (by throughput)	Average monthly ~$400-1,200 (3-node ms.kafka.large)

C client/individual developer: The open source version is completely free, and functional verification and prototype development can be completed on a stand-alone machine or in a Docker environment. In local development scenarios, the resource consumption of single-node Kafka + ZooKeeper (or KRaft) mode is controllable (2C4G can run).

Small and medium-sized teams/start-ups: It is recommended to start with Confluent Cloud or MSK Serverless to avoid initial investment in operation and maintenance manpower. Taking an average daily throughput of 100GB as an example, the monthly fee for a fully managed solution is about $300-800, which is much lower than the labor cost of an SRE required for self-hosting (monthly salary $8k-15k).

Enterprise/large-scale deployment: Self-hosted solutions have cost advantages at ultra-large scale (average daily PB level), but hidden costs are concentrated in three aspects - the time cost of cluster failure recovery, the business impact during partition rebalancing, and the engineering investment for cross-cluster data synchronization. Before purchasing, it is recommended that enterprises consider "3-year TCO (infrastructure + operation and maintenance manpower + failure loss)" as the core decision-making indicator, rather than just comparing the unit price of software licenses.

Main functions of Kafka

Kafka's capability system revolves around the three layers of "production-storage-consumption", but unlike a simple message queue, it provides engineering capabilities beyond basic functions at each layer:

• High-throughput persistent message engine: Supports write throughput of millions of messages/second, with a single message delay as low as 2ms (official website public data). Messages are written to disk in an append-only log structure, supporting multiple replicas (configurable replica factor 2-3) and multi-tenant isolation. The key difference from traditional message queues (RabbitMQ, ActiveMQ) is that Kafka consumers control the reading position through offset and support repeated consumption and historical backtracking, which is of significant value in data replay and failure recovery scenarios.

• Kafka Connect (Connector Framework): Through two types of connectors, Source (data source → Kafka) and Sink (Kafka → data target), two-way data synchronization with external systems is achieved. The community and Confluent provide hundreds of pre-built connectors covering JDBC, Debezium CDC, MongoDB, Elasticsearch, S3, HDFS, BigQuery, and more. Synergy: When Connect is used in combination with Kafka Streams, data can flow from the source system in real time and be directly written to the target system after stream processing without the need for additional orchestration layers.

• Kafka Streams (lightweight stream processing library): A stream processing engine based on Kafka's native logs. It is embedded in the application in the form of a Java library to complete filtering, aggregation, connection (Join), window operations, etc. Compared with external stream processing frameworks such as Flink/Spark Streaming, the advantage of Kafka Streams is that it has zero external dependencies - it directly reads Kafka topics, and the processing results are written back to Kafka. The entire pipeline is completely closed within the Kafka ecosystem.

• ksqlDB (stream processing SQL engine): SQL interface based on Kafka Streams, allowing stream processing logic to be defined through SQL statements. Hidden linkage: ksqlDB abstracts stream processing into two relationship models: "table" and "stream". Non-Java developers can also participate in real-time pipeline construction, but it is not suitable for complex state logic (such as multi-stage aggregation, custom window strategies). Such scenarios still require the use of Kafka Streams API.

• Schema Registry: manages and verifies the serialization format of messages (Avro, Protobuf, JSON Schema) to ensure schema compatibility between the production side and the consumer side. This is an easily overlooked but actually indispensable component in the production environment - without Schema Registry, schema changes will cause deserialization exceptions on the consumer side, and the troubleshooting cost is extremely high.

• Kafka REST Proxy: Produces and consumes messages through HTTP API. It is suitable for access scenarios in non-Java languages ​​or restricted network environments. However, the throughput is much lower than the native TCP protocol and is not suitable for high-traffic production paths.

Kafka’s model and version evolution

Kafka's version iteration follows the evolution model of "mainline release + KIP (Kafka Improvement Proposal) drive". Each major version introduces multiple KIPs involving protocol changes, new features, or architectural adjustments. The following are publicly verifiable version milestones:

Version	Release Date	Major Changes
0.7.x	2011	Initial open source version, basic messaging engine
0.8.x	2013	Introduce replication mechanism (Replication) to improve data reliability
0.10.x	2016	Introducing Kafka Streams (stream processing API)
1.0	2017-10	Milestone 1.0, API stability improvement
2.0	2018-06	Improve internal architecture and enhance security
2.8	2021-04	Introducing KRaft (Raft-based consensus mechanism) to eliminate the experimental phase of ZooKeeper dependence
3.0	2021-09	Remove support for Java 8 and Scala 2.12, KRaft enters preview
3.3	2022-09	KRaft ready for production (within 2000 partitions per cluster), KIP-405 elastic tiered storage
3.7	2025-12	One of the latest long-term stable versions; KRaft is stable and performance optimized
3.9.x	2026-06	The latest mainline version, continuing to enhance KRaft maturity and connector ecosystem

Mainline release (3.x series)

• Kafka 3.9.x (2026-06, no official precise date yet): The latest version. Continue to promote the stability and performance of the KRaft consensus model, enhance the integration of Kafka Connect and Schema Registry, and optimize the speed of partition rebalancing.

• Kafka 3.7.x (2025-12, no official precise date yet): the previous long-term stable version. KRaft mode can support larger clusters, and the Tiered Storage function continues to be optimized, allowing cold data to be offloaded to object storage to reduce local disk costs.

Architecture transformation stage (2.8 → 3.x)

Kafka 2.8 introduces the KRaft (Kafka Raft Metadata) mode, marking the beginning of Kafka's independence from Apache ZooKeeper. KRaft has gradually matured in the 3.x series, and by version 3.9.x, KRaft has become the recommended production deployment mode. The core benefits of this transformation are: simplified operation and maintenance (no need to separately manage ZooKeeper clusters), improved metadata consistency, and reduced cluster failure recovery time.

Candidate verification and patch release

In addition to the mainline version, Apache Kafka also maintains multiple patch versions (such as 3.7.1, 3.7.2), which usually include security fixes and critical bug fixes. It is recommended that production users always use the latest patch version instead of the latest mainline version to balance feature updates and stability.

Technical advantages of Kafka

Kafka's technical advantage comes from its "log-first" architectural design rather than a single performance indicator. The following dismantles its underlying mechanism and effects from three dimensions:

Architecture mechanism: Distributed log (Append-Only Commit Log)

The core of Kafka is an immutable log sequence - all messages are written to partitions (Partition) in append mode, and each partition is an ordered, immutable sequence of messages. Consumers track consumption positions by maintaining offsets instead of being pushed by brokers. This design brings two key effects:

• Decoupling of consumption and production: Consumers can consume historical messages at their own speed and even replay them from the beginning, which is crucial for the regeneration of AI training data or feature retrieval.
• Sequential I/O advantages: Append writing is disk sequential I/O, which is much faster than random I/O on mechanical hard disks. With the Page Cache mechanism of the operating system, Kafka can achieve write performance close to network throughput on cheap hardware.

Performance mechanism: Zero-Copy transmission

Kafka uses Linux's sendfile() system call in message transmission, and the data is copied directly from the Page Cache of the file system to the network card, bypassing the user space buffer. This mechanism allows Kafka's consumption throughput to be close to the upper limit of network bandwidth without being restricted by CPU processing power. Compared with push mode-based messaging systems such as RabbitMQ, Kafka's throughput is usually 5-10 times higher on equivalent hardware.

Scalable mechanism: partition parallelism and horizontal expansion

Each Topic can be split into multiple partitions (Partitions), which are the basic units of Kafka's parallel processing. The number of partitions directly affects consumption throughput - each consumer in the consumer group is responsible for one or more partitions. The more partitions there are, the more consumers can consume in parallel. But more partitions are not always better: too many partitions (more than 10,000 levels) will increase the metadata management burden on the controller, causing a significant increase in partition rebalance time.

Ecological Advantage: Connector Network Effect

Kafka Connect's hundreds of pre-built connectors create a "connector network effect" - the marginal cost of connecting new systems to Kafka continues to decrease. This effect is manifested in AI infrastructure scenarios as follows: the data source (business database, hidden logs, streaming media) → Kafka → feature storage/inference service link can be configured within a few hours, instead of weeks of custom development.

Technical comparison with competing products:

Comparing Dimensions	Apache Kafka	RabbitMQ	Apache Pulsar	Redis Streams
Message persistence	Disk persistence, multiple copies	Disk/memory, optional persistence	Layered architecture (BookKeeper storage)	Memory-based, optional persistence
Typical throughput	Million msg/s (single cluster)	~10-50k msg/s	Million msg/s	~100-200k msg/s
Message traceback	Supported (replay through offset)	Not supported (removed after consumption)	Supported (managed through cursor)	Limited (based on range query)
Stream processing capability	Built-in (Kafka Streams / ksqlDB)	None (requires plug-in)	Built-in (Pulsar Functions)	None
Deployment complexity	Medium-high (cluster planning required)	Low (can run on a single node)	Medium-high (multi-component deployment)	Very low
Optimal scenarios	High-throughput data pipeline, event sourcing	Low-latency task queue RPC	Multi-tenant, cloud-native messaging	Lightweight real-time queue, cache

How to use Kafka

Kafka provides multiple access paths, and the deployment method determines the initial experience and management overhead:

How to use	Applicable stage	Core features	Cost of getting started
Local development (single node/KRaft)	Learning verification, prototype development	Docker one-click startup, no need for ZooKeeper	Low (can start in 10 minutes)
Open source self-hosted cluster	Production is bounded	Full control, need to plan partitions/replicas/monitoring	High (requires operation and maintenance team)
Confluent Cloud (SaaS)	Small and medium-scale production	Fully managed, automatic scaling, pay-as-you-go	Low (API access is enough)
AWS MSK / MSK Serverless	Cloud-native production	Integrated with AWS ecosystem, Serverless auto-scaling	Medium (requires AWS infrastructure)
Confluent Platform (Enterprise)	Large-Scale/Compliance Production	Enterprise-level Security, Audit Multi-Region	High (requires business communication)

Typical local quick start steps (KRaft mode, without ZooKeeper):

1. Download the latest binary package of Kafka and unzip it: wget https://dlcdn.apache.org/kafka/3.9.0/kafka_2.13-3.9.0.tgz && tar -xzf kafka_2.13-3.9.0.tgz
2. Start a single-node Kafka cluster in KRaft mode:

   # Generate cluster ID
   KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"
   # Format log directory
   bin/kafka-storage.sh format -t $KAFKA_CLUSTER_ID -c config/kraft/server.properties
   # Start Kafka Server
   bin/kafka-server-start.sh config/kraft/server.properties

3. Create Topic and verify: bin/kafka-topics.sh --create --topic test --bootstrap-server localhost:9092
4. Use the console to produce/consume messages to verify connectivity: bin/kafka-console-producer.sh --topic test --bootstrap-server localhost:9092

Contextual implementation path for production: It is recommended to advance in three stages: "prototype verification → pilot docking → expansion evolution". In the first stage, a single node or managed service is used to verify the compatibility of connectors and data flows; in the second stage, a 3-node cluster is introduced to host 1-2 core pipelines to establish a monitoring and alarm baseline; in the third stage, partitions and nodes are expanded on demand according to traffic growth, and optional components such as Schema Registry and REST Proxy are incorporated into the architecture.

Product Pricing for Kafka

Kafka’s pricing path depends on the deployment model. The following are the three levels of fee boundaries:

• C-side/Individual Developer: Open source version Apache 2.0 license, zero software licensing fee. The cost of developing an on-premises or single-cloud VM is only the cost of computing resources (approximately $30-100/month). Confluent Cloud offers a free trial (typically with $50-200 initial credit) suitable for prototyping.

• Small and medium-sized teams/API integration developers: Fully managed solutions are recommended to avoid operation and maintenance manpower. Confluent Cloud is billed based on cluster throughput (MB/s) and storage (GB/month), and the monthly fee for a basic cluster starts at about $300; ​​AWS MSK is billed based on Broker instance specifications and storage, and a 3-node basic configuration is about $400-1,200/month. MSK Serverless automatically scales based on throughput and is suitable for scenarios with large traffic fluctuations, but the unit price per GB is usually higher than the preset capacity.

• Enterprise/Private Deployment: Open source self-hosting has marginal cost advantages at ultra-large scale, but the hidden operation and maintenance costs are significant. Confluent Platform Enterprise Edition provides RBAC, audit logs, Multi-Region cluster Schema Registry and full-time support. Subscriptions are based on the number of nodes. Specific prices require business communication. Before purchasing, enterprises need to confirm the following: cluster monitoring coverage, SLA compensation terms, and data migration costs from self-hosting to Confluent Cloud.

Note: The above prices are publicly verifiable reference ranges. The specific rates are subject to the Confluent Cloud real-time pricing page and AWS MSK pricing page. The open source version of Kafka itself has no vendor lock-in, but the migration cost of the hosting service (data volume × network fee) needs to be evaluated before signing the contract.

Kafka application scenarios

Kafka’s application scenarios cover everything from infrastructure-level log aggregation to AI-oriented real-time feature pipelines. The following are three typical implementation scenarios and their verification points:

• AI real-time feature pipeline: Online recommendation, real-time risk control, dynamic pricing and other scenarios require millisecond-level feature updates. Business events (browsing, clicking, ordering) flow into the feature store in real time through Kafka, and the online inference service consumes the latest feature vectors from the feature store. Key points to verify: Whether the feature update delay meets the model requirements (usually < 100ms); whether the ability to consume features retrospectively supports the reconstruction of training data. Implementation Tips: The high availability of the feature pipeline directly determines the quality of inference. It is recommended to configure a replica factor of 3 and producer acks=all for key feature topics to ensure that no messages are lost.

• Model Monitoring and Observability Data Flow: Inference requests, responses, latency and drift metrics issued by production models are transmitted to monitoring systems (such as Prometheus + Grafana or custom dashboards) through Kafka. Compared with traditional log collection solutions (such as Filebeat → Elasticsearch), Kafka, as a buffer layer, can cope with sudden peaks in inference traffic and prevent the monitoring system from being overwhelmed. Verification focus: Monitor whether the retention time of the data topic covers the lookback window required for model rollback (at least 7 days is recommended).

• Data Integration and CDC Bus: Synchronize change data capture (CDC) events of business databases to data lakes, search engines or downstream microservices in real time through Debezium connectors. This is one of Kafka's most classic scenarios - database → Kafka → multi-consumer fan-out architecture, which avoids repeated queries directly to the database. Cost reduction deduction: Taking an e-commerce platform as an example, the CDC pipeline of about 500 million order change events per day was migrated from batch processing (full scan every 10 minutes) to Kafka real-time streaming. The data delay was reduced from 600 seconds to less than 2 seconds, and the query load of the source database was reduced by about 70%. This deduction is based on public industry cases and is not an official commitment.

• Microservice event-driven architecture: Asynchronous event communication between multiple microservices through Kafka, replacing synchronous HTTP calls and reducing coupling between services. Human-machine collaboration boundary: Event publishing and consumption can be 100% automated, but irreversible operations (such as payment confirmation, order cancellation notification) should have a manual review confirmation point (Human-in-the-loop) set up at the consumer end to avoid the spread of automated misoperations.

• Log aggregation and telemetry data pipeline: Aggregate application logs and performance indicators scattered in various servers and containers into a unified data platform. Kafka acts as a buffer layer for "peak shaving" in this scenario - even if the log production rate is much higher than the consumption rate, Kafka's persistent log can ensure that data is not lost.

Applicable groups of Kafka

Kafka's multi-layered capability system allows it to serve roles with different technical depths, but the adaptation conditions for each role are significantly different:

• Data platform engineer/architect: Need to design cross-system real-time data pipelines, responsible for cluster planning, partitioning strategies, capacity evaluation and monitoring system construction. This type of role requires an in-depth understanding of Kafka's internal mechanisms (partition and replica ISR mechanisms, controller election), and the ability to tune JVM and Linux kernel parameters. Prerequisites: At least 3 years of experience in distributed system operation and maintenance, familiar with Java or Scala.

• AI Infra / MLOps Engineer: Embed Kafka in the feature pipeline and inference pipeline to ensure data freshness and replayability in online inference scenarios. Such roles do not need to go deep into the internal implementation of Kafka, but they need to understand the impact of the number of Topic partitions on consumption parallelism, the relationship between message retention strategies and storage costs, and the compatibility rules of Schema Registry. Prerequisite: Familiar with the basic architecture of AI model online services (feature storage → inference service → result writeback).

• Backend/Microservices Developer: Use Kafka client libraries (Java, Python, Go, Node.js, etc.) to produce and consume messages and build event-driven inter-service communication. The key thing to grasp is the offset submission strategy (automatic vs manual) and idempotence guarantee of the consumer group. Prerequisites: Understand the basic concepts of message queues and be able to read official client documentation.

• Data Analyst/Data Science Researcher: Consume data from Kafka topics for real-time analysis or model training data preparation through ksqlDB or Kafka integration with the data lake. This role does not directly operate the Kafka cluster, but needs to understand the format differences between streaming data and batch data. Prerequisite: Be familiar with SQL and understand the difference between event time (Event Time) and processing time (Processing Time).

Not suitable for boundaries: It is not recommended to use Kafka in the following scenarios - internal tools with extremely small data volume and no growth expectations (average daily message volume is less than 100,000), in which case RabbitMQ or Redis Streams is more lightweight; applications that only require simple task queues (no persistence, no retroactive consumption required); teams without any Java/Scala technology reserves and no willingness to operate and maintain, in which case Confluent Cloud or cloud vendor hosting products should be given priority.

Summary and Outlook of Kafka

Apache Kafka has established itself as the de facto standard in real-time data pipelines over the past decade with its distributed log architecture, high durability, and rich connector ecosystem. Its core competitive barrier is not a single performance indicator, but a complete ecosystem built around "log abstraction" - from connectors to stream processing engines, from schema registration to REST agents, Kafka provides an end-to-end data flow platform.

Current Limitations and Uncertainties:

1. Operation and Maintenance Complexity: The operation and maintenance threshold of a production-level Kafka cluster is still high, especially when it comes to partition rebalancing, cluster expansion and contraction, fault recovery, etc. Improper operation may lead to service interruption or data inconsistency. Although the KRaft pattern simplifies metadata management, the overall complexity is not significantly reduced.
2. Connector quality varies: Although there are a large number of connectors in the Kafka Connect ecosystem, connectors not officially maintained by Confluent vary greatly in reliability, document integrity, and version compatibility, and they need to be verified one by one before being put into production.
3. Cloud vendor lock-in risk: Although hosting services lower the threshold for daily operation and maintenance, in data migration and cross-cloud disaster recovery scenarios, migration costs (data transmission fees + application adaptation) may become a substantial lock-in cost.
4. Continuous adaptation of AI scenarios: As the demand for real-time data from AI workloads increases, the Kafka community needs to continue to optimize its capabilities in feature engineering, model training data provision, etc. through KIP, especially the optimization of partitioning strategies under the simultaneous requirements of high throughput and low latency.

Procurement/Adoption Risk Assessment:

For organizations planning to adopt Kafka, it is recommended to make decisions based on the following path:

• Pilot evaluation phase: First use Confluent Cloud or MSK Serverless to conduct a small-scale pilot for 1-2 months, and select 1-2 non-critical path pipelines to verify connector compatibility and latency indicators. Key measurements during the pilot period include: P99 value of message end-to-end delay, consumer lag fluctuation range, and cluster stability when traffic suddenly increases.
• Scale expansion conditions: When the pilot pipeline runs stably and the daily throughput exceeds 100GB or the daily message volume exceeds 100 million, it can be evaluated to enter the self-hosted or enterprise version plan. Before expansion, capacity planning (number of partitions × copy factor × retention time = total storage demand) needs to be completed and a monitoring and alarm baseline established.
• Enterprise Pre-Purchase Verification Terms: If you choose Confluent Platform Enterprise Edition, the SLA coverage (service availability vs. data durability), technical support response levels, data fees for moving in/out of self-hosting, and delivery boundaries for security audit capabilities (RBAC, audit logs, encryption at rest, network isolation) need to be clearly stated in the contract.

Version Info

• Apache Kafka 3.9 ：There is no official precise date yet. （2026-06）
• Apache Kafka 3.7 ：There is no official precise date yet. （2025-12）