Confluent Cloud Apache Kafka Client FAQ

You can connect to Confluent Cloud with Apache Kafka® clients in the language of your choice. Confluent maintains the Java Client and the C/C++, Python, Go, .NET, and JavaScript clients.

For an introduction, see Build Streaming Applications on Confluent Cloud. To configure your first client, see Kafka Client Quick Start for Confluent Cloud.

Client languages and versions

Which clients does Confluent support?

Confluent supports the following clients:

Java, which supports the producer, consumer, Kafka Streams, and Connect APIs.
librdkafka-derived clients, which support the admin, producer, and consumer APIs:
- C/C++
- Python
- Go
- .NET
- JavaScript

Confluent doesn’t support community-developed clients, including KafkaJS, Scala, Ruby, PHP, and Elixir.

For links to each client’s documentation and examples, see Client guides.

Which client versions does Confluent support?

Confluent provides maintenance fixes for two years with Standard Support and three years with Confluent Cloud Premier Support after the initial release of a minor version. For details about which client versions Confluent supports, including Java Development Kit (JDK) support, see Client versions and support.

Are older clients being dropped?

Yes. KIP-896: Remove old client protocol API versions in Kafka 4.0 deprecated older client protocols in Kafka 3.7 and removed these client protocols from Kafka 4.0. Confluent extends compatibility for Confluent Cloud clusters by one year. As of February 2026, Confluent Cloud rejects deprecated client requests with errors.

For the minimum compatible versions of each client, see Client Deprecation in Confluent Cloud.

Which Java version should I use?

Unless you have an architectural reason to do otherwise, use the newest long-term support (LTS) JDK that your Java client version supports. The latest Java client supports JDK 25.

For details about the JDK supported for each client version, see Java client support.

Connect Apache Kafka Clients to Confluent Cloud

What is required to connect a client to Confluent Cloud?

At a minimum, a client must:

Support TLS encryption and Simple Authentication and Security Layer (SASL) authentication, using SASL_PLAIN or SASL_OAUTHBEARER. SASL_OAUTHBEARER requires OAuth with OpenID Connect (OIDC) configured.
Include the Server Name Indication (SNI) extension in the TLS handshake.
Specify the cluster bootstrap endpoint and credentials.

For the complete list, see Client Configuration Settings for Confluent Cloud.

What ports does a client use?

Use port 9092 for Kafka protocol connections.

Use port 443 for REST connections, including:

Why does my client need to send the TLS SNI extension?

Confluent Cloud routes connections based on SNI. Confluent clients already send the SNI extension. Any forward proxy in the network path must forward the SNI extension unmodified.

For Kafka protocol connections on port 9092, the SNI extension must be set to the DNS hostname of the bootstrap endpoint or of a broker. Broker endpoints are discovered automatically during bootstrapping.

For REST connections on port 443, SNI must be set to the DNS hostname of the REST endpoint.

For more information, see TLS SNI extension requirement and TLS connectivity testing.

Can I use a custom DNS name for my bootstrap endpoint?

No. You must use the original cluster bootstrap endpoint name. If you point a custom DNS record at the cluster, TLS hostname validation fails.

Do I need to install CA certificates?

For Java clients, certificate authority (CA) certificates are typically already available in the JDK.

For librdkafka clients, including C/C++, .NET, JavaScript, Python, and Go, install Let’s Encrypt TLS certificates locally. On Red Hat Enterprise Linux (RHEL) and CentOS, the certificates are not present, so you must download them.

For librdkafka 2.11 and later, CA certificate discovery is typically automatic. For librdkafka versions 2.10 and earlier, you might also need to set ssl.ca.location.

For more information, see Client Configuration Settings for Confluent Cloud.

What are the recommended JVM settings for Java clients?

Set the following DNS-related properties so that clients pick up broker address changes promptly:

Java Virtual Machine (JVM) security configuration

java.security.Security.setProperty("networkaddress.cache.ttl", "30");
java.security.Security.setProperty("networkaddress.cache.negative.ttl", "0");

Kafka producer and consumer configuration

consumer.client.dns.lookup="use_all_dns_ips"
producer.client.dns.lookup="use_all_dns_ips"

For more information, see Client Configuration Settings for Confluent Cloud.

Configuration and error handling

Why do my clients log `NOT_LEADER_OR_FOLLOWER` warnings?

These warnings are expected during broker restarts, and clients recover automatically. Confluent Cloud performs rolling restarts of brokers during routine upgrades and maintenance. While a broker restarts, clients might briefly see warnings such as UNKNOWN_TOPIC_OR_PARTITION, LEADER_NOT_AVAILABLE, NOT_COORDINATOR, NOT_ENOUGH_REPLICAS, and NOT_LEADER_OR_FOLLOWER.

By default, producers retry for two minutes, and consumer and admin clients retry for one minute. Configure enough retries or retry time so these warnings do not surface as errors in your application.

For more information, see Cluster upgrades and error handling.

Why do my clients log `Connection to node terminated during authentication`?

A client logs this WARN message when it connects to a broker that has just restarted for maintenance. If this warning persists:

Check for a firewall that blocks Kafka TLS traffic on port 9092.
Confirm your credentials.

For more information, see Cluster upgrades and error handling.

Why do I get timeout exceptions under load?

Timeouts occur when clients exhaust the producer memory buffer while retrying or run out of time waiting for buffer space. Review your batching, retry, and buffer settings, and benchmark before tuning.

For detailed guidance, see Optimize and Tune Confluent Cloud Clients.

Should I increase the API version request timeout?

Yes. Before connecting a client application to Confluent Cloud, increase the timeout for API version requests from the default of 10 seconds:

For librdkafka clients, use api.version.request.timeout.ms.
For Java clients, use socket.connection.setup.timeout.ms, which bounds connection setup, including the API version request. On repeated failures, this timeout doubles up to socket.connection.setup.timeout.max.ms, which defaults to 30 seconds.

Consumers and share consumers

Should I use a consumer group or a share group?

Use consumer groups when you need ordered processing. Use share groups when you need parallelism beyond the partition count.

Consider these details when choosing a consumer group or share group:

Attribute	Consumers and consumer group	Share consumers and share group
Use cases	Stream processing, analytics, or extract, transform, load (ETL) pipelines	Task-queue and operational workloads
Ordering	Strict ordering within a partition	No guaranteed ordering
Scaling	Scales 1:1 with partitions	Scales beyond the partition count

For a more in-depth comparison, see Choosing consumer types.

How many consumers can I run in a consumer group?

Confluent Cloud doesn’t limit the number of consumers in a consumer group, regardless of your rebalance protocol. For best performance, keep your consumer group to 2,000 or fewer consumers. If you add more consumers than partitions, the extra consumers are idle. Partition count can constrain a consumer group because each partition is assigned to only one consumer in the group.

Share groups remove the partition constraint by allowing many share consumers per partition, but are limited to 200 share consumers per share group on Enterprise clusters and 1,000 share consumers per share group on Dedicated clusters.

For more information, see Kafka Consumer for Confluent Cloud, Share Consumers for Confluent Cloud, and Limits.

Do I have to use a consumer group at all?

No. If you want explicit control over partition assignment and offset management, call the consumer’s assign() method instead of subscribe(). With assign(), the consumer reads from the partitions you name and does not participate in group management, so group.id is optional.

If you commit offsets to Kafka, you must still set group.id, because it identifies where those offsets are stored.

For more information, see Choosing consumer types.

Test, tune, and monitor

How do I test a client application without a cluster?

Use a mock interface and test the utilities for your client:

JVM clients: MockProducer and MockConsumer
Kafka Streams: TopologyTestDriver and MockProcessorContext
librdkafka-based clients: rdkafka_mock
End-to-end tests: Testcontainers, which runs dependencies in Docker

For best practices, see Unit Testing and Integration Testing.

How should I benchmark my clients?

Establish a baseline with kafka-producer-perf-test and kafka-consumer-perf-test before introducing application logic.

For JVM clients, measure the resulting throughput with the Java Management Extensions (JMX) metrics that the Kafka producer and consumer expose. Run a single client on a single server. Repeat the test, adding client processes on each iteration, to find the number of processes per server that achieves the highest throughput.

For non-JVM clients, use rdkafka_performance. Then test your application starting from the default configuration and change one variable at a time. Use realistic data, especially when testing compression, because unrealistic mock data compresses better than production data.

Note

These performance test tools do not support Schema Registry.

For the full method, see Benchmarking.

What should I tune for?

Tune for one service goal at a time. These goals trade off against each other:

For more details, see Optimize and Tune Confluent Cloud Clients.

How do I monitor my clients?

Use the client’s JMX metrics or librdkafka statistics for application-side visibility, and the Confluent Cloud Metrics for cluster-side metrics.

For the metrics each client type exposes, see Producer Metrics and Consumer Metrics.

With KIP-714: Client metrics and observability, Kafka clients push their client-side metrics to the broker. In Confluent Cloud, client-side producer latency is the only KIP-714 metric surfaced in the Confluent Cloud Metrics.

Kafka Streams applications are an exception: they push a broader set of metrics through the same mechanism. For the list, see Kafka Streams client metrics.

For broader client-side visibility, collect metrics with JMX or librdkafka statistics.