APACHE KAFKA · INDEPENDENT ENGINEERING
Design, migrate and operate self-managed Apache Kafka, from KRaft clusters and partition design to upgrades and cross-cluster recovery, tested against your own workloads.
Independent Apache Kafka engineering.
These are independent Bassirah engineering and support offerings. They do not imply upstream vendor or foundation endorsement, official vendor support rights, enterprise feature entitlement or maintenance guarantees.
Apache Kafka, Kafka and the Kafka logo are trademarks of The Apache Software Foundation. Bassirah is not affiliated with or endorsed by The Apache Software Foundation, and is not a partner of Confluent, Amazon Web Services or Aiven.
Supported releases.
Apache Kafka is a project of The Apache Software Foundation, released under the Apache License 2.0. Bassirah provides independent engineering for the 4.4, 4.3 and 4.2 release lines, which the project lists as supported releases, and plans upgrades and ZooKeeper-to-KRaft migrations for clusters on earlier lines. The exact versions in scope are named in each statement of work. Last reviewed: 26 October 2026.
| Release line | Status on 26 October 2026 | How Bassirah treats it |
|---|---|---|
| 4.4 | Listed as supported; 4.4.0 released 22 October 2026 | Target for new deployments once clients, connectors and tooling are validated against it |
| 4.3 | Listed as supported; latest release 4.3.2, 23 October 2026 | Production target for upgrades where validation is complete |
| 4.2 | Listed as supported; latest release 4.2.2, 29 September 2026 | Supported; plan the next upgrade, since bugfix releases are made for supported releases only |
| 4.1 and 4.0 | Archived; latest releases 4.1.2 (17 March 2026) and 4.0.2 (16 March 2026) | Upgrade planning to a supported 4.x line |
| 3.9 and earlier | Archived; 3.9 is the last line with ZooKeeper mode, latest release 3.9.2 (21 February 2026) | ZooKeeper-to-KRaft migration on 3.9, then a planned upgrade to 4.x |
WHY IT MATTERS
Apache Kafka is an open-source distributed event streaming platform. Producers write events to topics, and consumers read them independently, so systems can share data without calling each other directly.
Topics are split into partitions spread across brokers, and each partition is replicated. Events are kept for a configured retention period rather than deleted after they are read. Since Apache Kafka 4.0, clusters run only in KRaft mode: ZooKeeper mode has been removed, and its metadata role is handled by Kafka’s own controllers. Partition keys, replication settings, retention and client configuration decide how a cluster behaves when load grows or a broker fails. Bassirah designs those choices for your workloads, tests them before production and keeps the cluster on a supported release line.
WHAT BASSIRAH DELIVERS
FIT FIRST
Apache Kafka adds a distributed system to operate. We recommend it when the workload needs a durable, replayable event log, and we say so when a simpler option is enough.
| Requirement | Apache Kafka is worth evaluating when… | A simpler option is often enough when… |
|---|---|---|
| Consumers | Several independent systems need to read the same events, at their own pace | One consumer processes each message once and then it can be discarded |
| Replay | Teams need to reprocess past events, for example to rebuild a view or recover from a bug | Messages have no value after they are processed |
| Volume and growth | Event volume is growing and must be spread across partitions and brokers | A single queue or database table handles the volume with headroom |
| Integration | Many sources and sinks need connecting through a common event backbone | Two systems exchange data on a schedule, and a batch job or API call is enough |
| Operations | Your team, or a contracted provider, will operate a distributed system, or you accept a managed service | You want the smallest possible operational footprint and no event platform to run |
Kafka is often paired with a stream processor. See our Apache Flink engineering page for stateful stream processing, and our real-time analytics solution for end-to-end designs. We never assume a workload needs Kafka until its consumers, replay needs and volumes are clear.
TOPOLOGY AND RESILIENCE
Apache Kafka replicates each partition across brokers inside a cluster, keeps cluster metadata in a KRaft controller quorum, can mirror topics to a second cluster with MirrorMaker 2, and can move older log segments to remote storage with Tiered Storage. Each option trades cost, complexity and data loss exposure differently. We choose them per workload, then prove the effect of a broker, zone or cluster failure in tested recovery exercises against objectives you approve.
| Decision | Typical approach | Trade-off we make explicit |
|---|---|---|
| Replication within a cluster | Partition replicas spread across brokers in different racks or zones, with the replication factor set per topic | Storage and network cost vs. tolerance of broker or zone loss |
| Producer durability | Producer acknowledgment and minimum in-sync replica settings chosen per topic | Write latency vs. the risk of losing acknowledged writes |
| Metadata quorum | KRaft controllers on separate nodes or zones, sized and placed by design | Number of controllers to operate vs. tolerance of controller loss |
| Replication between clusters | MirrorMaker 2, built on Kafka Connect, for active/passive or active/active designs | An independent recovery cluster vs. a target that can lag behind the source, and offset handling at failover |
| Long retention | Tiered Storage with a remote storage plugin for object storage or HDFS | Lower broker disk use vs. a plugin to supply and operate, and no support for compacted topics |
OPERATIONS
Choose partition keys, partition counts and retention so load spreads evenly and the ordering your consumers need is kept.
Review producer acknowledgments, batching and consumer group settings, and trace consumer lag back to its cause before changing configuration.
Rolling upgrades with checks for Java versions, client compatibility and removed features, rehearsed in staging with a decision point before metadata is finalized.
Broker and controller health, consumer lag, under-replicated partitions and disk growth with actionable alerts and capacity reviews.
KRAFT AND 4.X
Apache Kafka 4.0 removed ZooKeeper mode, so ZooKeeper-based clusters must be migrated to KRaft before they can be upgraded to 4.x. Delivered through our migration and modernization practice.
Start with a migration assessment of your clusters, clients and tooling.
USE CASES
Services that publish and react to business events, without calling each other directly.
Database changes and system events streamed to analytics, search and other systems through Kafka Connect.
Event streams feeding stream processors and analytical databases, where results are needed soon after events occur.
SUPPORT ROUTES
Apache Kafka is open source under the Apache License 2.0. Several vendors offer their own Kafka-based products and services, for example Confluent Platform and Confluent Cloud from Confluent, Amazon Managed Streaming for Apache Kafka (Amazon MSK) from Amazon Web Services, and Aiven for Apache Kafka. Bassirah supports the open-source Apache Kafka independently and is not a partner of these vendors.
| Decision factor | Community only | Bassirah independent support | Commercial vendor or managed service |
|---|---|---|---|
| Who operates Apache Kafka | Your team | Your team with Bassirah engineering, or Bassirah under a managed scope | Your team with the vendor's self-managed product, or the vendor for a managed service, under the vendor's terms |
| Help with incidents | Public community channels, no response commitment | Response targets per your agreement | Vendor support under the vendor's own terms |
| Code defects | Reported by you to the project | Reproduced, worked around and reported upstream by Bassirah | Handled by the vendor under its terms |
| Upstream fixes and releases | On the project's timeline | On the project's timeline; we track them, test them and apply them through change control | Under the vendor's terms |
| Commercial products | Not included | Not included: Bassirah does not resell or license vendor Kafka products or services | Contracted directly with the vendor |
If you need a vendor’s product, managed service or vendor-backed support, that is contracted with the vendor. How cases, severities and response targets work for our independent support is set out in our open-source support model. For fully contracted operations, see Managed Services.
WORKS WITH
Apache Kafka is one part of our streaming and real-time data practice. We place it alongside stream processing, analytical databases and object storage where each fits, and test every integration first.
Stateful stream processing over Kafka topics, when transformations, joins or windows need more than consumer code.
Real-time analytical queries over event data loaded from Kafka, with the ingestion path tested first.
S3-compatible object storage for data landed from Kafka, where your connectors and plugins are validated against it.
Contracted operations, monitoring and incident handling for Kafka estates.
Yes. Apache Kafka is a project of The Apache Software Foundation, released under the Apache License 2.0. Vendors such as Confluent, Amazon Web Services and Aiven offer their own Kafka-based products and services under their own terms. Bassirah supports the open-source project and is not endorsed by the ASF or by these vendors.
Yes. Apache Kafka 4.0 removed ZooKeeper mode, and ZooKeeper-based clusters must be migrated to KRaft before they can be upgraded to 4.x. The migration runs on the 3.9 line. After it is finalized, you cannot return to ZooKeeper mode, so we rehearse each phase first.
When one consumer processes each message once, when past messages have no value, or when a scheduled batch job connects the systems well enough. A simpler queue or integration is easier to operate. We say so in the fit assessment.
We work on the 4.4, 4.3 and 4.2 lines, which the project lists as supported releases, and we plan upgrades for clusters on earlier lines, including ZooKeeper-to-KRaft migrations on 3.9. The versions in scope are confirmed in each statement of work.
No. There is no official vendor support for the Apache project itself, and Bassirah is not a partner of Confluent, Amazon Web Services or Aiven. Our services are independent engineering and support, with scope and response targets defined in your agreement. Code fixes and releases follow the project’s timeline. See our support model.
Yes. Partitions are replicated across brokers within a cluster, which can be spread across racks or zones, and MirrorMaker 2 can replicate topics to a second cluster for disaster recovery or active/active designs. The target cluster can lag behind the source, so we design failover and consumer offsets for your objectives and test them.
Tell us about your clusters, workloads and recovery objectives. We will scope an assessment and a practical next step.
Operations & Reliability
Apache Kafka 4.x runs only in KRaft mode. ZooKeeper clusters must migrate on the 3.9 line first. How to plan the migration and the upgrade.
Apache Kafka
Read article : Apache Kafka 4 Without ZooKeeper: Planning the KRaft Migration and 4.x Upgrade→
