Kafka KIP Matrix

This document tracks krabka’s implementation status against the Apache Kafka Improvement Proposals (KIPs) that define Kafka’s compatibility surface: the wire protocol, message format, storage, replication, KRaft metadata quorum, security, authorization, quotas, admin APIs, queues (share groups), and the streams rebalance protocol.

It complements the wire-compatibility targets on the versions page. Where the two disagree, the differential test results behind the versions page win, and this matrix is corrected to match.

Target surface. Apache Kafka 4.x message schemas. The wire codec is generated from, and validated against, the Kafka schema corpus (the codec generator in krabka-protocol validates the 4.2 corpus, 197 schema files, and the 4.3.0 schemas are the target). Encode/decode is checked byte-for-byte against kafka-clients, and a JVM acceptance suite drives the official cp-kafka / apache/kafka admin tools against a live krabka broker.

Legend: ✅ fully implemented · ⚠️ partial (gap noted) · ❌ in scope but not yet implemented · ⛔ out of scope by design.

Scope. Kafka has ~1300 KIP numbers, but a large fraction are unassigned, withdrawn/discarded, folded into another KIP, or purely JVM-client-library / Kafka Connect / Kafka Streams-library internal with no broker or wire surface. This matrix is exhaustive over the KIPs that define krabka’s compatibility contract; the rest are handled categorically in §4 and §7. Numbers are not used as a count of implemented broker features.

1. Fully implemented (✅)

Wire protocol & message format

Producer — idempotence, transactions & EOS

Consumer groups & queues

Storage & log

Replication & availability

KRaft metadata quorum

Admin, configs & topics

Security & authentication

Quotas & throttling

Operator and Schema Registry compatibility

Observability & streams DSL/runtime (in the Rust Streams client)

The streams sub-KIPs below are implemented in krabka-client-streams, which is itself ⚠️ partial versus the JVM Kafka Streams library (see §2). They are listed here because the individual DSL/runtime features exist and are golden-tested against JVM capture.

Additional rows tracked by the broker’s generated matrix

The broker repository generates its own KIP matrix from the code and its tests. These KIPs are Implemented there.

2. Partially implemented (⚠️) — what is left

3. In scope but not yet implemented (❌)

No finite repository-local KIP outcome is currently classified here. New work belongs in this section only when it has a bounded behavior and acceptance gate.

Tracked horizons (not ❌ implementation commitments)

• krabka-client-streams is a Kafka Streams-inspired Rust API. Full drop-in JVM Kafka Streams library parity has no bounded feature list or acceptance gate; only separately scoped client features are implementation commitments.
• KIP-1150 is an accepted umbrella proposal that deliberately defines no code, public interface, documentation, or test changes. Its concrete follow-up KIPs are evaluated separately rather than treating KIP-1150 itself as unfinished code.

4. Deliberately out of scope (⛔)

5. Wire-level note

Several KIPs in §1 include byte-exact codec support generated from the Apache Kafka message schemas in krabka-protocol. Schema presence alone is not treated as full feature parity: entries that require broker behavior are listed as complete only when their handler semantics and behavioral tests are present as well.

6. Attribution caveat

The repo historically labeled the UnregisterBroker admin API (api_key 64) as “KIP-185”. Canonical KIP-185 is “Make exactly-once in-order delivery per partition the default producer setting” — unrelated. The UnregisterBroker feature itself is implemented and JVM-validated; only the cited KIP number was wrong.

This has been corrected throughout the source and README to KIP-919 (“Allow AdminClient to Talk Directly with the KRaft Controller Quorum and add Controller Registration”), which is the KIP that adds unregisterBroker support to the AdminClient (Apache JIRA KAFKA-17039). The underlying RPC originates with the KRaft controller surface (KIP-631). Release-managed CHANGELOG.md files were left untouched as historical record.

7. The long tail

Kafka has ~1300 KIP numbers. This matrix does not invent a row per integer, because a large share are unassigned/never-used, discarded/withdrawn/rejected, folded into another KIP, or JVM-client / Connect / Streams-library-internal with no broker or wire surface. Those are covered categorically in §3 (tracked Streams-library boundary) and §4 (out-of-scope ecosystems and client-library internals). Every KIP that defines krabka’s actual compatibility contract — protocol, storage, replication, KRaft, security, authorization, quotas, queues, and the streams protocol — is enumerated in §1–§3 and grounded in the repo.